UnifiedPush: A FOSS cross-platform push notifications protocol
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 287 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/57069 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Communications protocolReal numberInternetworkingTelecommunicationMobile WebReduction of orderServer (computing)Computer networkMessage passingIntegrated development environmentCache (computing)Communications protocolServer (computing)Real-time operating systemInstant MessagingSoftwareNumberConnected spaceInternettelefonieIntegrated development environmentMobile appDifferent (Kate Ryan album)TelecommunicationDiagramXML
00:53
Server (computing)Control flowLibrary (computing)Physical systemAxiom of choiceImplementationSimilarity (geometry)Open setIdeal (ethics)Client (computing)Matrix (mathematics)Virtuelles privates NetzwerkSocket-SchnittstelleDistributive propertyImplementationAndroid (robot)Domain nameMultiplication signMobile appArithmetic progressionIP addressRight angleCore dumpOpen sourceConnectivity (graph theory)Default (computer science)Event horizonWeb 2.0Matrix (mathematics)Socket-SchnittstelleSoftwareSoftware developerIntegrated development environmentServer (computing)CASE <Informatik>Internet service providerWebsiteProjective planeSingle-precision floating-point formatDifferent (Kate Ryan album)Connected spaceScheduling (computing)Library (computing)Power (physics)Standard deviationData storage deviceBitPoint cloudRoutingAxiom of choiceSet (mathematics)Latent heatFreewareMessage passingXMLComputer animation
07:11
Game theoryMessage passingDemo (music)Computer iconMessage passingMobile appMultiplication signInstallation artMatrix (mathematics)Ferry CorstenLink (knot theory)Software testingJSONXMLProgram flowchart
09:08
Data structureServer (computing)Uniform resource locatorInternet service providerMatrix (mathematics)Front and back endsInterprozesskommunikationPoint (geometry)File formatImplementationProxy serverSoftware developerGateway (telecommunications)Mobile appCartesian coordinate systemServer (computing)Latent heatCommunications protocolUniform resource locatorFront and back endsInternet service providerImplementationGateway (telecommunications)File formatProxy serverTelecommunicationJSONXMLUML
11:18
QuantumMobile appServer (computing)Cartesian coordinate systemRaw image formatUniform resource locatorMessage passingFile format
12:27
Message passingSoftware developerMobile WebOnline chatEncryptionGateway (telecommunications)Open setState of matterMessage passingMobile appStandard deviationRegular graphSoftware developerOnline chatBeta functionComputing platformLibrary (computing)Core dumpEncryptionWeb 2.0Server (computing)Projective planeRight angleGateway (telecommunications)Computer animation
14:22
Matrix (mathematics)EncryptionMereologyPlanningElectronic mailing listXMLUMLComputer animationMeeting/Interview
15:11
MereologyWeb 2.0outputMeeting/InterviewComputer animation
15:49
Server (computing)Mobile appMeeting/Interview
16:26
Android (robot)Process (computing)Multiplication signMobile appMeeting/Interview
17:00
MeasurementDefault (computer science)Asynchronous Transfer ModeMeeting/InterviewLecture/Conference
17:38
Server (computing)outputConnected spaceMeeting/Interview
18:12
Library (computing)Web 2.0EncryptionMeeting/Interview
18:46
Cartesian coordinate systemMereologyEncryptionMobile appPlanningSoftware developerGoodness of fitOcean currentComputer animationMeeting/Interview
19:25
Revision controlMobile appElement (mathematics)Matrix (mathematics)Android (robot)Client (computing)Open sourceServer (computing)Data storage deviceMeeting/Interview
20:27
WebsiteSoftware repositoryMatrix (mathematics)Meeting/Interview
21:10
Android (robot)AeroelasticitySoftware frameworkMeeting/Interview
21:45
Revision controlAndroid (robot)Multiplication signCartesian coordinate systemPoint cloudMobile appStandard deviationComputer animation
22:43
Operating systemInternet service providerServer (computing)Meeting/Interview
23:29
Endliche ModelltheorieTouch typingInternet service providerMeeting/Interview
24:08
Form (programming)Distribution (mathematics)Touch typingMultiplicationMeeting/Interview
24:40
Different (Kate Ryan album)Android (robot)Derivation (linguistics)Computing platformInternet service providerType theoryPresentation of a groupMeeting/Interview
26:07
Software developerPresentation of a groupWeb 2.0Android (robot)Right angleASCIIRegular graphServer (computing)EncryptionMeeting/Interview
27:20
Multiplication signSinc functionNP-hardCartesian coordinate systemMathematical optimizationForcing (mathematics)Connected spaceMobile appProduct (business)Digital rights managementSoftware developerProjective planeMeeting/InterviewComputer animation
29:26
Mobile appMathematical optimizationDigital rights managementInternet service providerMultiplication signTouchscreenPower (physics)Meeting/InterviewComputer animation
30:28
Software developerMathematical optimizationMultiplication signMobile appCartesian coordinate systemInternet service providerMeeting/InterviewComputer animation
31:02
Multiplication signRevision controlAndroid (robot)Open sourceDefault (computer science)Internet service providerServer (computing)Meeting/Interview
31:44
Right angleRevision controlOpen sourceFreewareCommunications protocolBenchmarkBuildingWeb applicationOrder (biology)ResultantMeeting/InterviewComputer animation
32:57
SoftwareIntegrated development environmentDifferent (Kate Ryan album)Router (computing)Connected spaceMeeting/Interview
33:39
SoftwareDifferent (Kate Ryan album)QuicksortFirewall (computing)Right angleMeeting/Interview
34:13
Internet service providerComputer animationMeeting/Interview
35:14
Right angleMetric systemMessage passingSoftware developerLibrary (computing)Online chatMeeting/InterviewComputer animation
36:06
Normal (geometry)Touch typingBus (computing)Revision controlMessage passingMeeting/Interview
37:13
Right angleServer (computing)BefehlsprozessorPower (physics)Process (computing)Computer programmingMeeting/Interview
38:13
Android (robot)Mathematical optimizationMeeting/InterviewComputer animation
38:57
AuthorizationGroup actionCartesian coordinate systemAndroid (robot)Right angleMobile appComputer animation
39:37
AuthorizationCartesian coordinate systemRight angleAndroid (robot)Revision controlBroadcasting (networking)Meeting/Interview
40:49
Right angleAndroid (robot)SmartphoneTheory of relativityOperating systemAxiom of choiceComputer animationMeeting/Interview
42:20
Computer animation
42:55
Meeting/InterviewComputer animation
Transcript: English(auto-generated)
00:05
Hi everyone, I'm here to talk about UnifiPush, an open, interoperable push notification protocol. So first, what are push notifications and why do we need them?
00:20
First, real-time communication apps like instant messengers and voice over IP apps need real-time updates over the internet. Also, mobile devices need to conserve battery, which means they should limit the number of server connections and only make these connections over efficient protocols.
00:42
Typical phones are constantly changing their network environment. They're jumping from like one wifi network to a cell network to a different wifi network. So the first possible solution to this notification problem is that each app could connect to its own server.
01:01
However, leaving connections up to each app means they might use different schedules for poll updates. And having multiple, possibly inefficient connections has the potential to increase battery usage a lot. Any apps that connect less often to save battery don't get instant updates. So in this case, this app that's connecting once every 15 minutes might not receive instant updates.
01:27
And this app that's connected persistently might consume a lot of battery. So the current solution to this problem is that all push notifications go through one centralized server, typically owned by your device OS company.
01:43
This is good for battery and all apps can receive instant updates. However, these servers are out of your control and require depending on third-party infrastructure. These push services also need proprietary libraries that have a lot of telemetry bundled in.
02:02
On the other hand, push notifications using unified push go through one single push server, but the important difference is that you control this push server. You can self-host a push provider or use a public one. Notifications going through one push server ensures that it's using a power efficient network protocol, but all apps still receive real-time updates.
02:30
So what is unified push really? Unified push is a standard that allows you to route all your push notifications through one server of your choice. At its core, unified push is just a set of specifications.
02:43
These specs have various FOSS implementations. And since it's a spec with free and open source implementations, it allows push notifications in app stores like FDroid, which only allows FOSS apps. Unified push has similar ideas to open push, which was a project that presented at FOSS STEM in 2020.
03:09
So a little bit about the history of unified push. Unified push was originally conceived as Godification by Simon, the project lead of unified push.
03:20
Godify is a notification server and Godification aim to give the ability to Godify to pass messages to other apps like Firebase cloud messaging did. Over time, it became clearer that having a spec would be much better than just one implementation. And thus, modern unified push came into being.
03:43
It was in December 2020 that Simon and Sandro wrote the Android spec and the domain unifiedpush.org was purchased. I also joined this project around this time.
04:01
Over the next few months, the seeds of unified push are sown. Two apps representing both social and instant messaging start supporting unified push. Three different distributors exist at this point. It's quite important to have multiple active implementations of a spec to ensure technology doesn't become too implementation dependent.
04:25
Since then, unified push has been seeing slow and steady progress. Six apps now support unified push and easier to use and self-host distributors have been created. Support for push notifications and mobile Linux also saw some work during this time.
04:48
To be usable with unified push, apps need to use the library and need to support it on their server. Two matrix clients, a FluffyChat and SkillyChat, a Mastodon client, Fedilab, a Trifa,
05:02
a talks messaging app, and an app called FindMyDevice currently support unified push. If you use any of these apps, you can get started with unified push right now. Distributors are the core of unified push.
05:21
Distributors are apps that distribute push notifications to other apps. They are often accompanied by a server component. Notify is the default recommended unified push distributor. It doesn't require any setup if you use the public server and even self-hosting it is super easy with the amazing documentation created by Philip, the developer of Notify.
05:47
It supports both server sent events and web sockets so you can use whichever technology works better for you battery and network environment wise. Secondly, NextPush is a unified push distributor that runs inside NextCloud to make it easy to host.
06:04
It uses server sent events as its transport. NoProviderPush is the simplest unified push distributor. It just spins up an HTTP server on your device and handles push directly from there.
06:20
It's made to be used with a permanent VPN where you have a static IP or for development. Godify is the app with which the unified push story pretty much started. It runs over web sockets. UPFCM distributor is a distributor that just wraps Google's FCM with a unified push API.
06:44
It's made in case you prefer using FCM. We want other apps to be fully FOSS or if your device manufacturer has extremely aggressive background app restrictions. You can find out more about how to use these unified push distributors on the unified push website.
07:16
Okay, now it's demo time. Here you can see SkillyChat, a matrix messaging app, is listening for notifications in the background.
07:28
Then I'll install Notify from Eftroid and I will open it once. After that, I quit SkillyChat so it can detect Notify on the next start.
07:43
And Notify now shows that SkillyChat is registered. Now if you exit SkillyChat, you can see that there's no background listener. And I'll send a matrix message from another device and it shows up.
08:14
Okay, this is another demonstration showing a UP example which is pretty similar to how a basic app using unified push would operate.
08:25
So when it doesn't detect a distributor or an FCM fallback, UP example shows a message saying it needs you to install a unified push distributor with a link to instructions. This is what a simple app implementing unified push would do.
08:44
Then we install a distributor, Notify, and registering UP example now shows an endpoint.
09:02
And we can receive test messages successfully. Do note that you don't actually have to click register buttons in an actual app. This is just because it's the example app that this happens. Okay, how unified push works. Getting into the technical details now.
09:22
So the first thing that happens when a new app wants to send a push notification using unified push is that it asks the distributor, the unified push app, what you have installed on your device for the endpoint. The endpoint is the URL at which the app server should send a push notification to.
09:42
The app then sends this URL to its server through whatever protocol it usually uses to communicate with the server. The server can be matrix masked on or any other backend the app uses. Now when the application server actually needs to send push notifications to the app,
10:02
it sends an HTTP post request to the endpoint the app sent it earlier and it's stored. This endpoint, which is the URL of the push provider, which is also known as the push server,
10:20
sends the notification to the distributor. The communication between the push provider and distributor is left up to the implementation and it's not specified by unified push. This allows for innovation in the network protocol used here.
10:41
This distributor then forwards this notification to the application that it belongs to. Sometimes the application server or push provider might not directly be compatible with unified push. A push gateway converts an application server's notification format into the unified push format,
11:04
whereas a rewrite proxy converts the unified push format into a push provider specific format.
11:21
Okay, so this is a demonstration of how an application server might send notifications to end user devices. Using up example again here, we can see that we got an endpoint URL from the distributor and using curl to do an HTTP GET request on the endpoint returns what is called the unified push discovery message.
11:44
This just means that this URL that's been specified is a valid unified push endpoint. After that, I'll do an HTTP push request with the body title equals hi and message equals hello.
12:01
This body can be anything for your app. It can be JSON, simple text, raw bytes, anything really. This particular URL encoded format is specific to the UP example app. After that, you can see that these requests result in notifications. Yay!
12:28
So, unified push on mobile Linux. Currently, there's no widely adopted push notification standard on regular mobile Linux, which is excluding a one-two touch. Unified push has the potential to be an open standard for push notifications on the Linux desktop and mobile.
12:47
Currently, we have a beta state spec that uses DBUS to pass messages and it uses DBUS activation to wake up apps. However, unified push on Linux and other DBUS platforms is untested and not widely adopted at all.
13:03
Support and guidance from experienced Linux app developers would be greatly helpful to make unified push on Linux possible. If you're a Linux app developer and are familiar with mobile things and would be interested in making unified push better, please join the chat.
13:27
So about encryption and web push. Core unified push is unencrypted for the sake of simplicity. However, depending on what kind of data apps might send over push notifications, apps may want to encrypt this data.
13:41
This is especially important for large public push servers. So on an API level, web push is almost compatible with unified push. However, a lot of advanced features of web push are not supported due to the simplicity of unified push. Though these issues can be resolved with a push gateway in the future.
14:05
Right now, creating an easy library to facilitate web push compatible encryption over unified push is an important goal of the project. It would help bring in well audited push encryption to unified push and would make web push compatibility even better.
14:23
Thank you all for watching. You can find out more on how to get started using unified push on our website, unifiedpush.org. And also a huge shout out to all the contributors of unified push and associated projects. Bye.
14:56
So thank you, Karmani and Simon. Let's now go to the Q&A part.
15:01
So we have a question here. Are there still no plans for standardizing a way to do end-to-end encryption for notification payloads? So there aren't any specific plans right now, but it's on the wish list. And it's one of the things we understand that is important and it needs to be done.
15:25
So yes, as stated, the missing part features are topics, TTL, VPED, etc. We have an issue on our GitHub, but with web push.
15:48
And iOS support is, so we don't really have any plans for that, given that it's way too difficult with all the restrictions on iOS.
16:06
What restrictions make that difficult? So iOS doesn't allow you to run background apps at all without Apple's push notification server.
16:20
So it makes unified push on there not feasible. So you have to use Apple's own stuff to do it. Is that it? Yeah, that's correct. And many Android manufacturers also do that.
16:40
But Android by itself, it does support running background apps. However, like OnePlus and Huawei and some other manufacturers actually kill a lot of background apps, which makes our job with unified push a lot more difficult. So they will kill by itself. I mean, they won't allow the background apps to go on for a long time.
17:09
Yeah, that's correct. Yeah. So they use modified Android or something? Yes, it's a modified battery saving measure.
17:20
Because of the battery saving? Yeah, it's a very aggressive battery saving measure. By default or only if the battery saver mode is on? It depends on the manufacturer. Some have it be able to disabled, others just don't.
17:41
They do only allow Google's FCM server. It becomes a similar problem to what iOS is, where you have to go through FCM to get your push notifications on those manufacturers.
18:03
I think Julen lost the connection. Hello? Oh, I'm sorry. Am I back? Yeah, you're reconnected. Oh, sorry, sorry. So we got a couple more questions. More of a common one of them. It would be nice to have a library maybe on top of unified push libraries to do transparent end-to-end encryption.
18:26
What's your take on that? What do you think about that? Yeah, so that's one of the goals along with web push and that whole library.
18:40
Simon, do you want to comment more on that? We were discussing about doing a library with web push over unified push. And I think it would be the best way to have end-to-end encryption over this notification.
19:03
But it's more already an application part on top of unified push. So another question. Are there any plans to onboard developers or apps that currently use the mainstream Google or Apple solutions?
19:24
Yes, that would be a very good thing currently. We have modified some apps that were previously using Google solutions like SkillyChat and FluffyChat and FettyLab.
19:41
All of these are matrix and Mastodon clients respectively. Their Play Store versions were using FCM and their Eftroid versions didn't have push notifications at all. And if they had it, it was through a background listener. So those are modified but more mainstream apps like not open source apps would be a little more challenging.
20:10
However, there's a pull request with Element Android. However, it hasn't gotten some attention from Element in a while.
20:23
So what was the FCM that you mentioned earlier? FCM is Firebase Cloud Messaging. It's Google's push server. So there's another question. Is there a good example on how to implement or integrate a unified push for my own server and app?
20:44
Yeah, there are a lot of examples and documentation on the unified push website, unifiedpush.org. And you can always just join the matrix room of unified push to discuss it more with us.
21:04
However, you should find examples on the website. Maybe the Git repo itself has some examples, maybe? Yeah, that's true. There's the Android example app, which it was one of the demonstrations during the presentation.
21:25
And that is used as like if someone wants to make an app, they can look at that to see how it's done. And there's also examples with Flutter and those are the two main frameworks that are supported by unified push right now on Android.
21:46
So the next question is, have you ported or integrated it in E Android OS, the E OS? Yeah, I don't think we've had anything related to that. Simon, do you know anything about that?
22:07
Yeah, E is like a deviation of lineage. So it's compatible. We can download the distributor on this version of Android and it will work.
22:22
I don't know if E wants or is planning to have a distributor installed by itself, maybe in a few times if there are more applications using it. Because they are using a lot of next cloud app already. So it can be possible.
22:43
Is the unified push available? I mean, meant only for Android right now? It's primarily for Android, but there are there's some work going on regarding Linux mobile. And those are the two operating systems now.
23:02
All right. There is something I mean, I heard that there are some other things called Ubuntu Touch or something. Oh, yeah, that's also based on Linux. However, Ubuntu Touch has its own push notification service. The only thing is like FCM and Apple's push service. It's also centralized and goes through their push servers.
23:28
So they also use this FCM and this Google and Apple stuff? No, it's a model similar to theirs. It's meaning that it's centralized and it's Ubuntu touches on push server, but having unified push.
23:45
So Google themselves run something similar to this Fireplace? Yes. It's called the Lumire push service. But hopefully we can have unified push on there as well.
24:01
Once we have Linux support better ready. And this Mobian is that's a Debian derivative, is it? Yeah, that's a form of Linux mobile. It's a distribution. So it would be nice to have a unified push on there as well.
24:26
And what voice does PinePhone use? Is it also Linux? It supports multiple. One of them is Mobian, as you said, and Ubuntu Touch and a lot of others. Or it's like a computer. You can use any voice.
24:44
And for regarding the Android, I don't know how to call it. It's different flavors. It's Lineage OS and Android. How do you call it? Is it Lineage OS, a derivative of Android or Lineage OS and a Replicant E, stuff like that?
25:06
E, Lineage and Google Android are different flavors of Android. But everything we have done for Android platform is working on it. So whatever works on Android with regard to unified push will work on all these stuff, right?
25:21
Yes, because it's not on top of any Google service. It's independent? Yes. I think that's all the questions right now.
25:46
So are there any more questions? Please type them away and we'll take it.
26:04
Meanwhile, I could discuss spec v2, which is something we've done after the presentation was finalized. And unified push is a constantly developing project. We're aiming to make it better.
26:20
And spec v2 is basically we realized that as the data from the server is encoded as a string, any high bytes, which are like from above 128, that's like outside of ASCII range, are lost.
26:43
And it's not a problem with regular JSON or whatever, but it is a problem when sending encrypted payloads, which is useful again for end-to-end encryption and web push. So spec v2 basically changes that on Android to make it so it sends bytes to the app,
27:05
like from the distributor to the connector, it sends bytes rather than a string. So that's the latest development in unified push since the presentation was recorded. Right. Cool.
27:22
So when you were developing this, when you were messing around with this, could you explain, I mean, since we have time now, would you mind explaining what all things that you went through and what all problems you faced and how did you go about fixing them?
27:40
You got time? Yeah. Do you mean like problems overall with UP or? Both actually, since if you have time. Okay. So one of the problems that I didn't face,
28:03
but the distributor developers as well as Simon, I'm sure, faced to the next push is having a battery efficient transport is pretty complicated. So they went through a lot of experimentation to get it efficient enough
28:23
and still not lose messages. So Simon, do you want to elaborate on that? Yes. Actually today, a lot of vendors are doing very hard optimization on battery. So we can often see a distributor being killed so we can't receive notification for the app.
28:48
And that's where we are playing around with a time to live between the force connection with product management. And that's all the idea behind this project is having only one application doing this work.
29:08
And the other developers and other application don't have to do it. So reducing optimization for one application and should save battery for all of them.
29:26
So instead of every app doing the same thing, this single one will do that, is it? Yes, exactly. And we have done some work on the battery optimization for next push and NTFI. And we've seen some increase, decrease of battery drain.
29:47
Mainly by stopping power management when they are not working. And we're doing other work on this with SparkChat's ideas.
30:08
So if the notification, I mean, just a basic question. If the notifications are to be handled, does that mean this one service or one app has to be on all the time
30:23
even when the phone is not, the screen is not on, right? So if every app was doing the same thing, that means the footprint on the battery would be more. I guess that's it, right? Yes, and the developers don't have to work on this and to do these optimizations every time.
30:46
We just have to have a few applications thinking about battery optimization. And so it is also simpler, so some app can focus on battery optimization.
31:01
This is one app or one service that can focus on the battery optimization and other apps can rely on that. I'm surprised that it takes, I mean, the OS right now that we have don't already do that. So I mean, I didn't know that the apps, all of them are doing this by themselves all the time.
31:25
So that sounds very inefficient. No, it only happens when using a fully free and open source version of Android. The default one with Google services has Firebase Cloud Messaging, which does that.
31:40
However, it goes through Google server. Oh, that makes sense. Right, right. Okay, so that may be one of the problems with using an open source version, I mean, but Google free version of Android, maybe like Linux. Oh, this or that could be okay, this could be very highly, it should fit well with that.
32:02
Okay, that would be cool. Right. So we got more questions. Let's see about SSE versus WebSockets. Why pick either protocol? It's like a web application.
32:21
Actually SSE is a build order and WebSockets may be easier to implement and WebSockets are more battery efficient. But I don't know which one is the best. On my side, I had better results with SSE and WebNext Push than Gotify, which uses WebSockets.
32:50
But it's mainly a developing tool. So we still don't have official benchmarks right now, like to scientifically measure how much battery is used by different protocols.
33:07
But it just depends on your network environment and different phones and battery situations. What do you mean by the network environment? The Wi-Fi strength or something different?
33:23
I mean by what routers you have, what sort of like how connections are killed on the network, long running connections, all of those behaviors can contribute. All right. So that means if the phone is connected, I mean connected to
33:43
the network for a longer time, more battery could be lost or something like that. Yeah. And SSE and WebSockets could have a difference based on like what sort of network you are on and what firewall is on there. Right. Cool.
34:01
So another question. Any experiment on using SMS to do the push signaling like waking up the phone and then press the notification using HTTP? We have runs, but it would I think it's a nice thing to try just for just for fun, maybe. I don't know.
34:22
Yeah, it sounds like it's interesting, is it? Yeah, though it'll be quite expensive. But it's a good experiment. I mean, why do you say it could be expensive? Because sending SMS requires a lot of money.
34:43
Or to get to the network provider. Yeah. All right. So I mean, yeah. So it could work maybe if you have a lot of SMS. So if you were supposed to be hypothetically if you were really using SMS for that, how many SMS would you want for an average user?
35:01
Just a guess. How many SMS do you think one would need for a phone? Just a guess. For metrics, it would be thousands per day, I think. Thousands per day? Yeah. I think Simon said dozens.
35:20
Dozens. Oh, okay. Cool. No, right. Thousands. With metrics. One to zero. Right. Yes. I guess it depends on how many messages you receive per day. That's an estimate, yeah. Just to know how expensive it could be.
35:42
Right. So another question. Is there a library that Android developers can use that would allow them to support both Unified Push and FCM so that they can use one single corporate instead of one Google and one Libre corporate? Is there something like this planned?
36:05
There is the answer in the chat. Yes, we have an embedded distributor. So the non-free flavor just have to embed this and it will receive a notification through FCM if the user wants to.
36:26
And another question. Purism develops a norm of GNU Linux-based Mobile OS, Pure OS derived from Debian. What about getting in touch with them for integrating Unified Push in it? What do you think?
36:43
Yes. So we have work ongoing with Unified Push on DBUS, which is the message bus that is often used on Linux distributors, including Purism's OS. And we would like to work with them in the future, but right now it's the Linux version of Unified Push is not ready.
37:10
However, we'd like to work with them in the future. Okay. So you are, you're already working on that right now, is it? Yeah, we're working on software for that, but it's not ready yet.
37:22
Yeah, yeah. Cool. Cool. Yeah. Right. Okay. So good to know that something is happening there too. Right. So I guess some questions may be coming. I see some people typing, but meanwhile, yeah.
37:54
Okay. I think this is what you said already. If you want to have only one process to get push
38:02
notification to save power, each program making up the CPU and asking the server for new data isn't very power efficient. I guess this is what you already said, right? Yeah.
38:23
So there is a comment which said that things are getting harder with Android 11 and 12. Any idea why that may be? It's true that Android is more aggressive about battery optimization with Android 11 and 12.
38:47
Also, another thing about Android 12, which will be harder for us, it's about... Another thing about Android 12 is what? Which will make things very hard for us. It's about the right to send items to other app and discover which have what actions.
39:16
I don't know yet how we will handle this because with Android 12, applications need to
39:27
have an authorization to look at actions on other applications. And that's what we are using today. I mean, in Android 12, applications need to have what? You said something. I couldn't get that.
39:41
Authorizations to know which application. Okay. All right. Right. Cool. All right. Okay. Cool. So, I mean, is it possible that suppose a new Android version comes and is it possible for them to
40:10
have some feature or a new thing which can make things even more difficult for a unified push to come in? Is it possible even hypothetically? Just to know.
40:26
I don't know if it can be done because a lot of applications are working on broadcasting and I don't think they can totally stop it.
40:44
They can make things difficult too, is it? Yes. What it's doing with Android 12 already is difficult. Right. They can make things difficult, but they will probably be reluctant to completely do away with it.
41:00
Exactly, yes. So they are cool. That's how it usually happens with regard to Android. They would want the people to stick with Android and unified push is not exactly tied with the Android. That's what you said, right? It's independent.
41:21
Yeah, that is true. However, Android is a big operating system and it's very important in the OS world. Yeah, true, true. Yeah, totally true. I forgot the percentage, but I guess it's safe to
41:41
say more than 70% of the smartphones that we have today are Android based, right? And that may be too liberal, but still. Right. So we have a comment that says we have to promote unified push to Huawei and other vendors, get it integrated in linear choice.
42:06
I'm not sure here, but is there any relation with Huawei and Lineage OS? I guess not, is there? Maybe it's a big question, but...
42:21
I don't think it would be embedded with vendors like this. It can be a user lens, so... User lens? Yeah, no, it doesn't have to be a vendor part, so user can choose the distributor that's the ID. So I don't know if they're getting it.
42:43
Yeah, I think... I don't know. I also think it's possible, but it's unlikely, at least right now. Okay, cool. I think we have taken all the questions now.