WEBVTT 00:00.000 --> 00:11.960 So, we are going to talk about push notifications on mobile and unified push, and we are 00:11.960 --> 00:13.160 Daniel and Simon. 00:13.160 --> 00:21.720 Daniel is developing the XMPP client conversations that can be used to get push notifications 00:21.720 --> 00:23.720 with unified push. 00:23.720 --> 00:29.120 And on my side, I've started the project like five years ago, and I developed a development 00:29.120 --> 00:43.640 and then there are libraries and some applications. 00:43.640 --> 00:46.120 Yes, awesome. 00:46.120 --> 00:51.080 Let's start this talk by asking ourselves the question, how do notifications actually get 00:51.080 --> 00:52.080 to my phone? 00:52.080 --> 00:58.520 How can my email application know that I have like new email and notify like tell me or 00:58.520 --> 01:00.520 the user about it? 01:00.520 --> 01:07.400 So, the easiest approach to this is like ask the server if there's new email in like periodic 01:07.400 --> 01:09.640 in top of like every 15 minutes or so. 01:09.640 --> 01:15.520 And this is basically the approach that pops free back in the day used. 01:15.520 --> 01:21.360 And can I get a quick show of hands on how many of you have been around for long enough 01:21.360 --> 01:24.640 to have fetched the email of our pops free? 01:24.640 --> 01:27.640 Who still fetching the email of our pops free? 01:27.760 --> 01:30.080 Okay, two, three, very brave people. 01:30.080 --> 01:31.080 Thank you. 01:31.080 --> 01:38.440 So, yeah, like the diagram shows, every 15 minutes or so on set interval, I'm going to ask 01:38.440 --> 01:42.600 myself, is an email and a lot of cases you're going to say, no, you don't have any 01:42.600 --> 01:46.920 new emails and then occasionally server goes, oh, you have no emails. 01:46.920 --> 01:53.080 And there are a lot of pros and cons to that approach. 01:53.080 --> 01:57.600 One obvious pro is that it's like very easy to implement. 01:58.400 --> 02:01.640 But the downsides are that it's very expensive. 02:01.640 --> 02:06.600 Like the flow chart I showed you like didn't even show like the whole things that usually 02:06.600 --> 02:09.840 you don't just ask for like new emails. 02:09.840 --> 02:15.120 You also have to like establish a TLS connection, hopefully, before and then you have 02:15.120 --> 02:18.200 to lock in and stuff like that. 02:18.200 --> 02:24.200 And just as far as the user visible notifications, our concerns might be like a 02:24.240 --> 02:25.200 high latency, right? 02:25.200 --> 02:30.840 Because like if you're asking every 15 minutes, you might have to wait like 14 minutes 02:30.840 --> 02:36.880 on and 59 seconds at the worst case to get notified of an email that just arrived shortly 02:36.880 --> 02:38.920 after the last time you checked. 02:38.920 --> 02:43.800 And yeah, and also like the vast majority of connections will be like unnecessary 02:43.800 --> 02:49.800 because like unless you're like a very important person, like a lot of like those checks 02:49.800 --> 02:54.160 you're just not going to have like new emails. 02:54.160 --> 03:02.000 And then there's the more modern approach that IMAP uses these days, for example, where 03:02.000 --> 03:07.000 you build up like one connection maintains the connection for as long as possible. 03:07.000 --> 03:12.840 You establish TLS ones, you authenticate ones and then you're just going to like instruct 03:12.840 --> 03:18.880 these server to give you over the existing connections like a short shout out is there's 03:18.880 --> 03:19.880 like new emails. 03:19.880 --> 03:24.280 So you just maintain the connection, wait and then occasionally the server's going to tell 03:24.280 --> 03:31.760 you that says new email and again that's how IMAP works. 03:31.760 --> 03:39.720 And yeah, so the zero behind that is that network connection that doesn't do anything 03:39.720 --> 03:42.080 doesn't actually consume that much of a power, right? 03:42.080 --> 03:48.840 Because like your mobile, your mode, then it's going to go into like power saving mode and 03:48.840 --> 03:54.840 like yeah idling doesn't do a whole lot on the modem side of things and also on the 03:54.840 --> 03:55.840 operating side of things. 03:55.840 --> 04:00.680 It's just like a few bytes in the kernel somewhere reminding you that there's a connection 04:00.680 --> 04:03.280 but like nothing actually going to be done. 04:03.280 --> 04:09.880 That's that's a series, but in practice unfortunately it isn't that simple because of like 04:09.880 --> 04:12.840 next and weird networking situations. 04:12.840 --> 04:16.960 You have to do like period of things to check if the connection is still alive, you have 04:16.960 --> 04:22.640 to read doubly see connection entirely if you switch from like Wi-Fi to mobile or if you 04:22.640 --> 04:27.600 went to airplane mode for a little bit of time or draw through tunnel or whatever. 04:27.600 --> 04:32.960 So you have to like manage the connection, it's not just a state of connection and that would 04:32.960 --> 04:38.000 be theoretically fine but if you have multiple apps running on your phone then this thing 04:38.000 --> 04:44.640 is not like not synchronized across apps like various apps will ping at various intervals 04:44.640 --> 04:52.000 or do the reestablishing light, one will do it like slightly later than the other one and 04:52.000 --> 04:59.040 this goes against the principle of the principle of power saving that says like transmit 04:59.040 --> 05:03.440 as early as possible and when you do send as much as possible at once but it's basically 05:03.440 --> 05:14.480 like power managing trick for your modem and this also can be done in like the management 05:14.480 --> 05:19.600 can be like messed up a little bit like it's it's difficult to like implement correctly it's 05:19.600 --> 05:26.000 it's a bit not not more science but yeah you have to like put some sort and effort into it 05:26.000 --> 05:33.120 and like for example if you are comparing signal which is directly connected to the signal server 05:33.120 --> 05:38.960 like so signal in mode where it doesn't use Google push notifications but like tries to maintain 05:39.440 --> 05:44.960 the connection to the server directly if you compare that to conversations on next 05:44.960 --> 05:53.120 if you decline doing the exact same thing we can see that like signal is doing a worse job 05:53.120 --> 05:58.240 at the same task right and like obviously the signal developers very likely on stupid 05:58.240 --> 06:03.280 anything but it's just a show that you have to like put a lot of like effort and dedication 06:03.280 --> 06:11.840 into like managing this this connection properly yeah and just all kind of like raises a 06:11.840 --> 06:17.600 question can be it not simply combine this maintaining of like one connection into like one 06:17.600 --> 06:22.240 app like have just maintained one connection to a server somewhere and have that connection 06:22.240 --> 06:28.160 being managed properly and yeah the answer is that's basically what a firebait cloud 06:28.160 --> 06:36.960 messaging is or what Google push is and then I very deliberately use like proprietary 06:36.960 --> 06:43.440 services on one hand like for example we have like FedEx which like wants to notify 06:43.440 --> 06:50.080 my my FedEx mobile app that like I don't know my delivery has like an update or whatever 06:50.080 --> 06:56.560 and then the service like FedEx upcoming that example will tell over like a proprietary 06:56.560 --> 07:03.280 API will tell the Google servers the Google servers will over that over one persistent 07:03.280 --> 07:07.440 connection tell what's got the play services like a background service that's running on like 07:07.440 --> 07:14.400 most Android phones will tell that and then the app will wake up the play services will wake up 07:14.400 --> 07:22.320 the app that that should receive the notification and yeah same thing if like for the 07:22.400 --> 07:27.520 love times that app if our flight gets later whatever it all gets pushed over that one channel 07:30.160 --> 07:34.720 and yeah so as I said like the replay service is maintained like one persistent well managed 07:34.720 --> 07:42.560 connection to Google servers but there's like it's a good implementation of like that problem 07:42.560 --> 07:47.120 but there isn't any like magic behind it it's just like does he kind of opinions you reconnect 07:47.920 --> 07:53.600 and all that it's just like implemented well and relatively efficient and then 07:54.960 --> 07:59.360 yeah the correlation between like which service and one supposed to which app 07:59.360 --> 08:04.000 happened over like so-called tokens and it's used for like the correlation between 08:04.000 --> 08:08.960 the servers and the app and yeah by default if you just buy like a stock 08:09.840 --> 08:17.520 Android phone somewhere yeah a very few things work without Google push like for example 08:18.160 --> 08:23.520 apps that wanted to maintain like their own persistent connection would need explicit user content 08:23.520 --> 08:28.000 and there's like a annoying proper notifications and also if you want to distribute 08:28.960 --> 08:33.680 the apps through the Google Play store then it has like additional limitations on top of that 08:33.680 --> 08:38.320 where like only certain kinds of apps are allowed to maintain their own persistent connection 08:38.400 --> 08:43.520 like for example like instant messaging app but like your game or whatever probably wouldn't be allowed to 08:43.520 --> 08:50.560 to have that yeah and there's obviously like a lot of like criticism uh towards Google with 08:50.560 --> 08:56.080 regards to like the enforcement of every app having to use like Google push notifications 08:56.960 --> 09:01.840 so one of the arguments is yeah Google just wants total control and I guess there's probably 09:01.840 --> 09:07.200 some truths to that but also as I showed earlier like implementing like push notifications 09:07.280 --> 09:11.680 yourself isn't like completely trivial and you don't want to like burn like every developer 09:13.440 --> 09:18.400 with that and then uh like on the on the app side like in some case or in a 09:18.400 --> 09:22.320 lot of cases Google doesn't actually see any content because in a lot of cases it's just like a 09:22.320 --> 09:26.640 wake-up signal and like a dumb wake-up signal that doesn't actually tell you anything 09:26.640 --> 09:29.840 or for example it's a signal case just all we have like something happened there are new 09:29.840 --> 09:36.400 notifications that there's like not the actual message content in there so it's not as worse as some 09:36.480 --> 09:43.280 people say this but yeah it's certainly not good either and it's usually type to your Google account 09:44.400 --> 09:52.000 and there's also like a whole lot of more criticism with regards to Google push that we don't have 09:52.000 --> 09:56.640 time to go into but if you don't have the slides you can have a look at like a lot more arguments 09:58.320 --> 10:03.520 to that slides are linked in the or only for them perhaps that by the way 10:04.000 --> 10:10.160 um so yeah this raises the question uh can we not have the same thing but like open source 10:10.160 --> 10:17.600 and different for last and uh yes we can and um that's uh unified push so uh the the the graph looks 10:17.600 --> 10:22.320 very similar to the one I showed you earlier uh except uh is this time I used like open source 10:22.320 --> 10:28.720 services I used like master don't as an example and and fast millers a nice email provider and then 10:28.720 --> 10:35.360 like open source apps tasky that's a master don't client let us that's an email client and um 10:35.760 --> 10:40.960 so in this graph you're going to introduce like the the solid lines are like what what's going 10:40.960 --> 10:46.400 to be like a centralized protocol and then the dotted lines are like proprietary things and like 10:46.400 --> 10:52.720 in the uh unified push uh mental model the place services the thing that runs on your android 10:53.360 --> 10:59.680 basically replace with something that's called like a distributor and um there are various implementations 10:59.680 --> 11:05.360 for distributors and then every uh distributor goes along with like one particular implementation 11:05.360 --> 11:09.760 not one particular instance but one particular implementation of of a push server uh and that's 11:09.760 --> 11:14.720 because like the the protocol that the distributants push server are talking to each other that's like 11:14.720 --> 11:21.360 like not standardised uh exactly but but what is standardised is the communication between the 11:21.360 --> 11:28.960 apps that once they use unified push and the distributor and um between like the service and uh 11:28.960 --> 11:36.560 what I called the push server that's both standardised and on the android sites is uses just standard 11:36.560 --> 11:42.000 android interprocess communication like broadcast intends they are called if you're familiar with uh 11:42.000 --> 11:48.080 android development and on the other side on the service to push so what we use like a fairly well 11:48.160 --> 11:54.880 established um internet centers called web push which is also what um website that wants to like send 11:54.880 --> 12:00.160 push notifications through a browser which use uh that's basically yeah that's the things that like 12:00.160 --> 12:07.600 all browsers implement these days and it's like i test standards like various um there is iFCs and stuff 12:07.600 --> 12:13.040 and through the fact that it's like a well established web standards like a lot of lectures out there 12:13.040 --> 12:18.320 because due to the fact that they want to create uh notification in the browser already have support 12:18.320 --> 12:24.080 for that push like for example like master don't already have support for that and um yeah they're also 12:24.080 --> 12:30.400 like other uh things that already have support for it for for example jamep which is like a modern 12:30.400 --> 12:37.200 dairy placement for i-map and uh calda and calda and stuff like that natively comes with web push support 12:37.280 --> 12:46.080 and then there are extensions to like even some areas like iFC to trigger uh web push notifications directly 12:46.640 --> 12:53.840 and like even if the service you want to talk to doesn't uh yet support that push that's uh 12:53.840 --> 12:59.120 web push is still actually most likely candidate uh to be like adopted by them so for example there's 12:59.120 --> 13:05.440 currently talks on to like retrofit that push into i-map that's so even if you're using an email server 13:05.920 --> 13:13.840 uh that uh doesn't the web game of all whatever then you could potentially uh still negotiate 13:13.840 --> 13:20.320 like uh web push with an i-map server and again not synthesized this uh what's being talked 13:20.320 --> 13:28.480 between the district attorney and anti-push server um yeah and the redistributor basically does 13:28.480 --> 13:34.960 the managing of a persistent TCP connection that i'm better talked about uh earlier and um 13:35.040 --> 13:42.160 unified push actually has like a variety of um distributors to choose from and yeah this kind of 13:42.160 --> 13:49.040 like establishes a little bit of a competition between the uh different um uh between the 13:49.040 --> 13:54.960 different distributors on like who can manage the connection like the most efficient way or whatever 13:54.960 --> 14:03.120 and like various uh distributors use there is protocols to talk to their respective um push server 14:03.120 --> 14:11.120 so web sockets is used a lot as these days but uh uh servers and events like events or CHDP 14:11.120 --> 14:16.880 long polling sing is used by some of them and um we can also use something like xnp which is what 14:16.880 --> 14:25.120 uh conversations does uh and yeah xnp also like very efficient and very good at like uh it's 14:25.200 --> 14:32.000 establishing a uh good quality permanent connection that doesn't consume a lot of resources 14:33.600 --> 14:41.920 and yeah this is a graph on uh how likes entire process what work and again uh the solid lines 14:41.920 --> 14:48.000 are like what's standardized and the dotted lines are like then what um the various 14:48.080 --> 14:55.760 where the various services are have like uh their own proprietary protocols find so tasky again 14:55.760 --> 15:01.440 that's like a uh a method on app what uh center registration request to the distributor um 15:03.280 --> 15:08.560 and then the distributor would go talk to the push server and try to register and get like a 15:08.560 --> 15:16.960 that push URL uh back like that pushes just like that's in HDP URL uh get that back to the distributor 15:16.960 --> 15:22.480 over whatever like protocol distributor and push server have in common and then the distributor can 15:22.480 --> 15:29.520 tell the um the app in question like uh tasking this example oh here see the URL and then 15:30.640 --> 15:37.680 tasky or any other again uh uses the the uh that push end point and and hands it over all the 15:37.680 --> 15:43.520 way to the to the service and that's like the one time registration that you do one time like 15:43.600 --> 15:48.560 really you first set up your account in tasky or when you first open the app or whatever and then um 15:50.080 --> 15:55.760 here again if then Macedon or whatever like actually wants to like notify me of a new boost or like 15:55.760 --> 16:03.600 or like a new direct message I got in it would over um web push tell the push server over the 16:03.600 --> 16:10.320 URL then the push server would over the established communication channel uh tell the distributor 16:10.400 --> 16:14.880 and then the distributor would send uh again and that's again something to size because like 16:14.880 --> 16:20.640 um tasky is the support that would send a broadcast intent Android IPC thing to tasky with the 16:20.640 --> 16:28.560 contents of the push notification and yes if you want to try it yourself um a very quick and easy way 16:28.560 --> 16:36.240 to uh get started would be to pick the distributor uh son up um for people who are very keen on like 16:36.240 --> 16:44.320 hosting the push server part of that um themselves uh notify and next push thing I think that 16:44.320 --> 16:50.560 are a little bit obviously you can sell for all of them but like so as the ones that are like um 16:50.560 --> 16:55.680 very easy to set up next push kind of like works with the next cloud uh instance that some of you 16:55.680 --> 17:01.680 may or may not have so if you already has that like go for that and if you are already uh a job 17:01.680 --> 17:06.720 of an example user or uh want to become one and use that for like you know further rated 17:06.720 --> 17:13.360 instead of messaging needs same conversations uh can also act as a distributor and and use the 17:13.360 --> 17:20.000 example pick connections that um conversation already holds in the background uh to also fan out 17:20.000 --> 17:25.040 push notifications and yeah on the app side of things there are actually already like a lot of 17:25.040 --> 17:31.920 apps that uh support unified push um so yeah there's a lot of like mastered on apps uh tasky fatty 17:31.920 --> 17:38.560 lab uh but there's also other interesting apps like for example duff x5 that's a calendar card 17:38.560 --> 17:44.720 depth synchronization thing um then letters that's an email client which is a jammer protocol 17:45.600 --> 17:51.440 fan x that's the uh don't want to say open source version of firefox but the more open version of 17:51.520 --> 17:56.880 firefox that's distributed uh via android for example that actually has um unified push support 17:57.840 --> 18:05.600 internally and then then molly that's uh for walk of of signal has support for um unified pushes 18:05.600 --> 18:10.880 well and there are a lot more apps and you can find them on our website and and browse through them and 18:12.640 --> 18:19.680 yeah and maybe it's coming like is it to your app like the app you are developing um or like an app 18:19.760 --> 18:24.560 you're using because it's uh it actually makes life for app developers a lot easier because they don't 18:24.560 --> 18:29.200 have to maintain it complicated like permanent connections themselves and but uh uh unified push itself 18:29.200 --> 18:35.920 is like very easy to implement uh for the the apps uh apps side of things that's basically like 18:36.880 --> 18:43.120 library that does all the the IPC stuff on android that's called the connect a library uh you could 18:43.120 --> 18:47.680 technically if you're like a little bit more familiar with android development issued the uh broadcast 18:47.760 --> 18:54.400 intense and stuff all yourself um or you can connect a library whatever you prefer and on the 18:54.400 --> 18:59.440 server side of things if you're not using like masterdom but are writing your own server for like 18:59.440 --> 19:04.640 whatever um then there are already like a lot of like that push libraries out there because again 19:04.640 --> 19:10.000 like that push is a big established standard for browsers and like if you have some sort of server 19:10.000 --> 19:15.280 thing that wants to interact with your app then yeah lots of library support for that as well 19:15.920 --> 19:22.240 and yeah because this is like uh frost on mobile and and android is increasingly turning 19:22.240 --> 19:30.320 the not frost way unfortunately I also want to briefly mention Linux on mobile and uh unified push 19:30.320 --> 19:37.200 does actually have a debust API that's specified like the same kind of like interactions that I 19:37.200 --> 19:43.200 described to you earlier um this far there aren't that many implementations is on the distributor side 19:43.360 --> 19:49.680 on the app side of things of these unified push debust API but yeah I'm personally interested in 19:49.680 --> 19:53.120 in working on that he's probably interested in working on that and a lot of the 19:53.120 --> 19:58.000 experience that we gained with like implementing that uh for android is like very likely to 19:58.000 --> 20:03.360 transferable to the to the Linux side of things as well and yeah a lot of shared knowledge lot of 20:03.360 --> 20:10.160 gained experience can be um put into these a little of some mobile and select debust thing as well 20:10.240 --> 20:14.080 and yeah I'm now going to turn it over to the 7 for the quick down 20:23.280 --> 20:27.120 so yeah let's see oh it works 20:32.080 --> 20:36.320 so I've my my phone there and um I have a distributor which is a snap 20:38.000 --> 20:40.000 already installed 20:40.320 --> 20:45.600 and for the example that we use uh six ampere up so I just have to register 20:47.200 --> 20:53.360 yeah I can choose which distributor I want to use and which one we will be my default one because 20:53.360 --> 21:02.640 I have many of them and that's it I just get an end point where which can be sent to my server 21:02.640 --> 21:13.040 that will be available to send to my mobile mobile phone so if I send a notification we can see 21:13.040 --> 21:23.760 that are received one um which will be more interesting is if we send it from another application 21:25.200 --> 21:32.480 or another device if you want you can test it and just send a random message and I should 21:32.560 --> 21:35.600 be receiving I should receive them on my phone 21:50.400 --> 21:54.400 so 21:55.360 --> 22:01.360 and what are content 22:05.760 --> 22:09.600 and when these uh I think the content has a notification so you can see them 22:12.000 --> 22:16.000 but I receive many of them 22:24.400 --> 22:30.720 okay so that's it's sorry 22:38.320 --> 22:40.720 and most important if you have questions 22:54.400 --> 23:02.000 and it will need the permissions to uh which permissions needs the distributor to 23:02.000 --> 23:11.760 run on the device and basically it will need two permissions one to show a notification 23:11.760 --> 23:20.080 which is required to get uh four guns service and the permission to run in the background 23:20.080 --> 23:24.080 visit a teamyzish 23:25.760 --> 23:33.200 yeah try this a question so uh deal with the server to distribute messages just to be 23:33.200 --> 23:38.560 the bottom of the stations would be an interesting for the uh uh three-letter agencies 23:38.560 --> 23:44.320 it would be interesting to be hacked in etc so I do uh how in power included the notifications from 23:44.400 --> 23:53.120 the uh from the providers to up to the phone is there an encryption or is it uh 23:53.120 --> 23:58.960 included in cryptics by the server etc so the question is as the person notification 23:58.960 --> 24:08.160 encrypted and yes there are encrypted following the RFC 82 91 which is the web push on 24:08.720 --> 24:16.000 encryption are they encrypted from the from the application server to the device to the 24:16.000 --> 24:30.640 phone or can I yeah so yeah I think quickly go back to the so there's basically like two 24:30.640 --> 24:39.360 encryption's going on so if the uh Macedon server is sending like a push notification to our 24:39.360 --> 24:43.840 task is it actually has a actually has content because like a lot of push notifications are just 24:43.840 --> 24:48.080 wake up signals that don't have any content but like in the Macedon example there's actually 24:48.080 --> 24:54.160 any content in there the Macedon server can basically do like enter an encryption to the app 24:54.240 --> 25:02.880 we're only the app has the um private key to decrypt that right and then there's like another 25:02.880 --> 25:06.960 layer of encryption on top of that or beneath that if you will then the communication between 25:06.960 --> 25:11.920 the distributor and the push server is usually like TLS encrypted and stuff of that that's how it says 25:15.920 --> 25:20.320 is there a coupon you could write a distributor yourself it doesn't do that but like 25:20.320 --> 25:25.040 the distributors I listed they are used either like HTPS for the ones that use like web 25:25.040 --> 25:31.440 sockets and stuff or um the one that uses XMP obviously also uses TLS because like TLS mandatory for 25:31.440 --> 25:37.840 for XMPP okay so the only thing that push server or C is that the Macedon has sent an 25:37.840 --> 25:46.560 notification to you yes the only thing uh the push server C is uh from whom to whom basically so 25:46.720 --> 25:53.040 that something goes from master down to to to to nap but yeah obviously the goal is also I mean you 25:53.040 --> 25:58.560 can self-help the push server right so the push server is very little but you can also sell 25:58.560 --> 26:10.240 for us or put it like to a trusted party yes is there any delivery success reporting you can check 26:10.240 --> 26:22.880 when the notification was received or not so web is there a delivery notification for the push server 26:25.120 --> 26:35.440 yeah success reporting um the RFC 8030 web push or RFC define a way to to get this report 26:36.400 --> 26:43.200 but we don't see any push server doing it right now uh made me the Mozilla one google one or any 26:43.200 --> 26:50.400 other implementation but usually when your application receives the notification it's kind of to a 26:50.400 --> 26:56.880 request to your own server so this is the way you do 27:05.440 --> 27:12.080 it's not I try to implement it and I will see notifications only what's on the side right is the 27:12.080 --> 27:19.520 app expected to stay running in the background and we'll get sure it's on the location um even on a mobile 27:19.520 --> 27:25.360 phone uh the application can be started from the push notification but for if you shut doesn't implement 27:25.360 --> 27:34.960 it yet I'll just have to like three three lines of code to do because it has been a really 27:35.280 --> 27:49.120 recent version of the virtual library it's started after a restart of the phone do we need to restart 27:49.120 --> 27:56.800 the distributor and no there is a different way to start automatically your application when the phone 27:56.880 --> 27:58.800 puts 28:15.840 --> 28:21.040 the question is the is the service on mobile phone unlinics mobile phone 28:22.000 --> 28:29.440 origin start and does it need to run as a system and today the service isn't 28:29.440 --> 28:40.160 started by default but so you can install on the most Linux distribution and it runs as a user service 28:51.040 --> 28:55.360 in fact my question is in the card below but to my knowledge there are apps like 28:55.360 --> 29:01.040 signal apps and others when they are installed they check in the have access to the 29:01.040 --> 29:05.840 group names are received and if they don't have access to this they will manage themselves 29:06.480 --> 29:12.400 the issues with the way you just show us with a little battery clean and so 29:13.440 --> 29:20.000 and what what my knowledge when this first choice is done in the app after that is that I do 29:20.000 --> 29:27.600 certainly are you allowed or integrate the real businesses the app will remain on the first 29:27.600 --> 29:34.160 choice and so the question would be between of your android one suddenly 29:35.920 --> 29:44.960 installed and not on the internet in the file push would be apt to be capable of suddenly choosing 29:44.960 --> 29:54.960 to go on mobile phone push or you have to read on the left means toilet so the question is 29:56.480 --> 30:06.160 are you able to use unified push after using your own application if you install the service 30:06.880 --> 30:13.520 and you did the example of signal who can't use the press service if you see if there are 30:13.520 --> 30:21.360 installed afterwards and this is a client-side implementation they choose to not support it once they 30:21.360 --> 30:29.680 have checked it it's perfectly possible to use your unified push service afterwards and usually 30:29.680 --> 30:40.000 most application gives an option to change your service if you want okay so if you want 30:40.000 --> 30:44.880 you will be able to decide if you have other questions yes thank you all