WEBVTT 00:00.000 --> 00:10.400 Hello everyone, and thank you for being here in this talk, we'll talk about new pipe and 00:10.400 --> 00:14.000 how it was for at it to sail fish or us. 00:14.000 --> 00:19.040 So first of all, who am I, I'm Fabio Germán Asio, it's also known as Staipox Online. 00:19.040 --> 00:24.000 I'm the maintainer of new one of the maintainers of new pipe, and also I created an assistant 00:24.000 --> 00:27.320 for Android called Dicho, which is available on Android. 00:27.320 --> 00:31.320 I'm a member of the new pipe association, and also for local hack space. 00:31.320 --> 00:37.320 I'm currently studying in ETH, in Zurich, and yeah, you can find my details there. 00:37.320 --> 00:39.320 Then we have David. 00:39.320 --> 00:40.320 Thank you very much. 00:40.320 --> 00:43.320 Hi, I'm David, Lauren and Jones. 00:43.320 --> 00:49.320 I am not a new pipe developer, but I am a member of the self-ish OS community, 00:49.320 --> 00:53.320 and I have the privilege of meeting some of the new pipe dev team last year at 00:53.320 --> 00:54.320 them. 00:54.320 --> 00:58.320 Try it out, and we're so taken by it that I was really keen to see whether it would work on 00:58.320 --> 00:59.320 self-ish OS. 00:59.320 --> 01:04.320 So, after Fabio has talked about a new pipe protocol a little bit more about 01:04.320 --> 01:06.320 putting it to self-ish OS. 01:06.320 --> 01:12.320 Yeah, I briefly started with a quick introduction of what new pipe is in case some of you 01:12.320 --> 01:17.320 don't know about it, so it's basically an Android app that lets you watch YouTube videos, 01:17.320 --> 01:21.320 or those videos from other streaming platforms. 01:21.320 --> 01:24.320 Yeah, it's completely open-source. 01:24.320 --> 01:26.320 It's available on Android. 01:26.320 --> 01:31.320 You can use it also as a way to get more privacy when watching YouTube videos. 01:31.320 --> 01:36.320 For example, because the official YouTube app tracks and everything. 01:36.320 --> 01:39.320 So, I will go through some of its features. 01:39.320 --> 01:44.320 So, here, number one, you can obviously search for stuff. 01:44.320 --> 01:50.320 For videos, you get videos, playlists, channels, then you say that you tap on a video. 01:50.320 --> 01:55.320 Number two, you will get a video with a bunch of information about it, such as comments, 01:55.320 --> 01:59.320 description, a bunch of actions you can do. 01:59.320 --> 02:03.320 Number three, you get recommended videos and related videos. 02:03.320 --> 02:07.320 And finally, number four, the important thing is you actually get to play the video. 02:07.320 --> 02:10.320 And the player is one of the most important parts of the app. 02:10.320 --> 02:17.320 Since it's very complicated and it allows you to play stuff in the background, 02:17.320 --> 02:22.320 or even in a pop-up that goes other other apps. 02:22.320 --> 02:28.320 You can build a queue of multiple songs to listen to and so on. 02:28.320 --> 02:32.320 Then onto other features, we have the possibility to download stuff. 02:32.320 --> 02:36.320 So, download music, download videos, download subtitles. 02:36.320 --> 02:41.320 Then one interesting thing is that you can book my playlists. 02:41.320 --> 02:45.320 And this might seem simple, like it's just a link to a remote playlist. 02:45.320 --> 02:52.320 But we actually have another feature which is you can build playlists out of videos that are stored locally in the app. 02:52.320 --> 02:57.320 And this works not just for YouTube, but for all of the services that are supported by new pipe. 02:57.320 --> 03:01.320 And you can build playlists that contain videos from multiple services. 03:01.320 --> 03:07.320 So you can have some YouTube videos together with some peer-tube videos and so on. 03:07.320 --> 03:11.320 And the number three you can see how the playlists you are looks like. 03:11.320 --> 03:15.320 Then moving on to more multi-service features. 03:15.320 --> 03:20.320 We have subscriptions which also just work across all services together. 03:20.320 --> 03:24.320 We have a unified feed for all of your subscriptions. 03:24.320 --> 03:28.320 So basically what new pipe does is it keeps these subscriptions locally. 03:28.320 --> 03:34.320 And it makes a network request for each of the subscriptions every time you reload the feed. 03:34.320 --> 03:37.320 And it just aggregates everything together. 03:37.320 --> 03:44.320 And again, this works not just for YouTube, but for all channels you subscribe to from every service. 03:44.320 --> 03:51.320 And yeah, finally number three you can see that new pipe actually supports YouTube, SoundCloud, MediaCC. 03:51.320 --> 03:56.320 All possible peer-tube instances and Bandcamp. 03:57.320 --> 04:01.320 How does this multi-service support work go? 04:01.320 --> 04:06.320 Because you might understand that it could be high to implement it in the absence. 04:06.320 --> 04:12.320 Every service has a totally different interface for fetching stuff for how it needs to be handled. 04:12.320 --> 04:24.320 So what we did to make sure that things work at simple and clear interface is that we developed a completely separate library called new pipe extractor. 04:24.320 --> 04:29.320 Which doesn't rely on any of the Android APIs. 04:29.320 --> 04:32.320 It's fully like it's plain Java. 04:32.320 --> 04:35.320 You can use it in any Java project actually. 04:35.320 --> 04:43.320 And what this library does is it provides unified interface for all of the services. 04:43.320 --> 04:52.320 And then internally, it does all of the things that need to be done in order to get data from some specific service. 04:52.320 --> 05:01.320 For example, YouTube has to make some requests in some way SoundCloud has to make you have to make requests in some other way and so on. 05:01.320 --> 05:05.320 And how do these requests actually look like? 05:05.320 --> 05:11.320 So for example, say that we want to search for something on YouTube. 05:11.320 --> 05:13.320 So we write the query in the search bar. 05:13.320 --> 05:21.320 And if we were going to open the accessibility, so the developer tools in Firefox or in any other browser, 05:21.320 --> 05:25.320 we would see that the browser made a request. 05:25.320 --> 05:31.320 And that the request number three contains a bunch of JSON information. 05:31.320 --> 05:37.320 And yeah, what the extractor does is it basically makes the same requests that the web browser would do. 05:37.320 --> 05:41.320 And then extract this information to show it nicely in the app. 05:41.320 --> 05:46.320 It's a bit harder for videos because YouTube openskates stuff and so on. 05:46.320 --> 05:50.320 But yeah, this is basically basically it. 05:50.320 --> 06:00.320 On a completely separate topic, you know, when you have an app that is used by a lot of people who have all different needs. 06:00.320 --> 06:05.320 They come from different backgrounds, they want to do different stuff with the app. 06:05.320 --> 06:10.320 Sometimes it's hard, it's hard to come up with UI that works for everyone. 06:10.320 --> 06:13.320 You don't have to read the text here, it's just an example. 06:13.320 --> 06:25.320 But the point is that sometimes you have to make high decisions to build your eyes in a way that tries to meet as many needs as possible. 06:25.320 --> 06:29.320 And this is an example of what we did a few couple of years ago. 06:29.320 --> 06:36.320 So we had to redesign the action buttons under the videos because there were too little space and we need to add more. 06:36.320 --> 06:42.320 And so we came up with three possible designs and then had people vote. 06:42.320 --> 06:49.320 And yeah, we have to do many of these kind of say surveys. 06:49.320 --> 06:53.320 It's not actually a survey, but yeah, many of these decisions. 06:53.320 --> 07:01.320 For example, now we are working on refactor in your pipe to improve it UI, which has started to feel a bit old. 07:01.320 --> 07:15.320 So we want to update it to newer material design, new material design guidelines and also better like code under the hood. 07:15.320 --> 07:26.320 And so for example, in number one, we have the new long press menu, which is another example of trying to fit together as many needs as possible while making the interface. 07:26.320 --> 07:34.320 Still accessible for people that just downloaded the app for the first time and don't know anything about it. 07:34.320 --> 07:43.320 So we have the new long press menu, which allows you to do a bunch of actions when you long press on videos or long press on channels or long press on playlist. 07:43.320 --> 07:55.320 You have icons, you have text previously, we only used to have some text in the middle of the screen and was high to read the high to add new options to little space now. 07:55.320 --> 08:07.320 It's better hopefully. The number two we have improved the comments UI, it's not a separate page anymore, it's a proper pop up from the bottom. 08:07.320 --> 08:23.320 And finally, number three, we have a new player for the application, which will hopefully replace the current one and fix many of the related bugs that sometimes pop up in the player we have right now, which is. 08:24.320 --> 08:28.320 It has been called the spaghetti monster of doom. 08:28.320 --> 08:35.320 So yeah, thanks to Shabby, who should be in this room for making that player. 08:35.320 --> 08:39.320 And yeah, with this, I will switch over to David. 08:39.320 --> 08:42.320 Thank you very much. 08:42.320 --> 08:50.320 Okay, I'll just put myself up because I might need a pace. 08:50.320 --> 08:52.320 I think that works great. 08:52.320 --> 08:58.320 Yeah, thanks very much for a brilliant introduction to new pipeline explanation of the features barrier. 08:58.320 --> 09:07.320 So as I mentioned before, I tried new pipeline last year at Fosden because I was basically given this flyer and tried it out on Android. 09:07.320 --> 09:11.320 And as you've just seen it, it has a lot of really brilliant functionality. 09:11.320 --> 09:19.320 And I'm a selfish OS user, so I was really keen to see whether or not that functionality could be ported on to selfish OS. 09:19.320 --> 09:22.320 Oh, not to see it. Sorry, no, no, it's okay, it's okay. 09:22.320 --> 09:28.320 So selfish OS, if you're not familiar with it, is a Linux based operating system for mobiles. 09:28.320 --> 09:31.320 That has its own user interface, it is GNU slash Linux. 09:31.320 --> 09:34.320 So it has a sort of a GNU user space. 09:34.320 --> 09:38.320 So it's a little bit different from Android and quite a bunch of different ways. 09:38.320 --> 09:41.320 One of the ways it's different is that it is called self-ish OS. 09:41.320 --> 09:43.320 Everything is nautically themed. 09:43.320 --> 09:47.320 And so the name change from new pipe to self-ish OS as it went through that transition. 09:48.320 --> 09:50.320 Okay, now it's good. Cool. 09:50.320 --> 09:57.320 So one of the big difficulties that are getting new pipe to run on self-ish OS is that new self-ish OS doesn't have a Java runtime. 09:57.320 --> 10:03.320 And of course, Android apps are written in Java or something that compiles down to Java bytecode. 10:03.320 --> 10:05.320 So you need a JVM in order to run it. 10:05.320 --> 10:08.320 And without that, of course, that's a problem. 10:08.320 --> 10:14.320 The good news is that a member of the selfish community developed something called sailing to coffee, 10:14.320 --> 10:21.320 which is a way of compiling down Java source code to native executable to run on self-ish OS, 10:21.320 --> 10:25.320 using something called the Grow VM native image compiler. 10:25.320 --> 10:30.320 So it compiles it down to native code and then you can run it without the need for a JVM. 10:30.320 --> 10:36.320 And so that was what I thought would be neat to try with new pipe to see whether or not that would work. 10:36.320 --> 10:43.320 And then the functionality that then you get an executable library and that functionality can be exposed using Java native interface. 10:44.320 --> 10:54.320 And you can then link that to a C++ or C or some other native executable and execute the code in the Java as if it were just like a normal executable. 10:54.320 --> 10:57.320 There are some restrictions with using Grow VM. 10:57.320 --> 11:01.320 For example, you can't use reflection, which you would normally do with Java and certain things like that. 11:01.320 --> 11:06.320 So that adds some complexity, but in theory it should be possible. 11:06.320 --> 11:11.320 But there are some other restrictions as well, because you also don't have the Android libraries. 11:11.320 --> 11:15.320 So it's user interface libraries, for example, on your system. So you need to get around that. 11:15.320 --> 11:23.320 And one of the really nice things about new pipe is that it is split into this extractor that Fabio explained before that deal with all of the back end services. 11:23.320 --> 11:27.320 It deals with interacting with YouTube and SoundCloud and Bankamp and all of the others. 11:27.320 --> 11:32.320 And then the user interface code, which is actually, it's not just separate, it's in a separate repository. 11:32.320 --> 11:35.320 So they're very clearly defined, very clearly separated. 11:36.320 --> 11:54.320 So the idea then is to expose the new pipe extractor code through using this small shim that gives us a Java native interface to some C++ code, which then uses a cute user interface, which is what self-ishores typically uses for its app integrations. 11:54.320 --> 12:02.320 And then you get a nice self-ishores like experience in the user front end, but you get all of the nice functionality that new pipe provides from the back end. 12:02.320 --> 12:07.320 And for people to use self-ish, that's really nice because they get something that they're familiar with in terms of user interface. 12:07.320 --> 12:17.320 And of course native applications are something that self-ish users generally encourage because it helps the ecosystem. 12:17.320 --> 12:23.320 So this is another diagram that kind of shows how the extractor and the UI works on Android. 12:23.320 --> 12:30.320 So this is the Android approach where you have the extractor that deals with the back end and the user interface that is also written in Java. 12:30.320 --> 12:35.320 That's some Kotlin on the user interface side, and they interact with each other using Java calls. 12:35.320 --> 12:41.320 So to convert that to using Grow VM, we end up with something that looks like this. 12:41.320 --> 12:47.320 I want to shout out to Jerome, who has done all of the images for this. 12:47.320 --> 12:50.320 Thanks so much for the great images. 12:51.320 --> 13:08.320 And the way it works on self-ishores is that we compile the extractor down into a Java into an executable library, a native executable library, with this very small shim wrapper that converts all of the data types into JSON on one side. 13:08.320 --> 13:17.320 And then we have some C++ code on the other that converts all the JSON back into C++ structures on the other side, and then the two can interact with each other essentially using JSON. 13:17.320 --> 13:24.320 And then you get this QML side to do with the user interface and the back end. 13:24.320 --> 13:35.320 So the whole effort of going through the process of converting it took in my estimation about six weeks of full time development time that was split across 200 days. 13:35.320 --> 13:42.320 And I want to shout out to all of the people that followed that took part in that process with me. I really appreciate it to your support. 13:42.320 --> 13:46.320 So it was quite a lot of work to get things to the place where it works. 13:46.320 --> 13:50.320 But in practice, I actually only touch the surface of the new pipe functionality. 13:50.320 --> 13:55.320 You saw all of the stuff going on in new pipe. There's a lot more that could be integrated. 13:55.320 --> 14:02.320 But one of the things that I was really pleased to discover is that the Java compiled down to native code was really performant. 14:02.320 --> 14:06.320 Much more performant than I was expecting. I thought I would end up with something that was slow and hard to deal with. 14:06.320 --> 14:12.320 But it actually works really well, really nicely, even though there's not this JVM in the back end. 14:12.320 --> 14:17.320 And you can see in the images that on the left-hand side is the Android interface. 14:17.320 --> 14:24.320 And you can see a lot of the Android functionality shown there in terms of viewing videos on the right-hand side as the self-issue and OS interface. 14:24.320 --> 14:29.320 And you can see that they are different. They have interfaces that match the platform that they run on. 14:29.320 --> 14:34.320 But you can also see similarities hopefully in functionality across the two as well. 14:34.320 --> 14:43.320 So some of the drawbacks and benefits of doing this approach of porting Android apps to self-issue S. 14:43.320 --> 14:50.320 In terms of benefits, well, the real big benefit is that the new pipe development team do all of the hard work, right? 14:50.320 --> 14:57.320 That's the main benefit. So self-issue S users gain from all of this fantastic work that this team of devs do. 14:57.320 --> 15:01.320 And they can just pull in that, we can just pull in that capability and make use of it. 15:01.320 --> 15:06.320 And that's actually really important especially for new pipe because Google changes the back end. 15:06.320 --> 15:11.320 The code needs updating to support it. It's a lot of work to keep the two in sync. 15:11.320 --> 15:15.320 It's a lot of effort to keep the two in sync. 15:15.320 --> 15:19.320 And so it means that you don't have to duplicate all of that effort. That's really important. 15:19.320 --> 15:21.320 So that shared functionality is really nice. 15:21.320 --> 15:25.320 On the other hand, there's no compromise in terms of the look and feel. 15:25.320 --> 15:28.320 The Android app looks like an Android app. It's self-issue out, looks like a self-issue OS app. 15:28.320 --> 15:32.320 And users get what they expect on the device that they're using. 15:32.320 --> 15:39.320 And in this practice I mentioned before, the performance of compiling down the code to a native executable is actually 15:39.320 --> 15:42.320 End up being really performance and surprisingly good in practice. 15:42.320 --> 15:50.320 So it actually works really well. There is some work to be done to implement the shims, but in general it actually works very nicely. 15:50.320 --> 15:57.320 So those are the benefits. There are of course drawbacks and the biggest drawback is that you have to have this really clear functional 15:57.320 --> 16:01.320 separation between the back end code and the front end code. 16:01.320 --> 16:05.320 And you pipe happens to have that. And when I started this project, I didn't know that it was just a really lucky 16:05.320 --> 16:10.320 care instance that it worked out that way. If it hadn't done it, it would have been a bit of a disaster. 16:10.320 --> 16:15.320 And not all Android apps, although it is good practice, are separated in this way. 16:15.320 --> 16:19.320 They often have joined tighter coupling between the two. 16:19.320 --> 16:22.320 So it only really works when you have that sort of situation. 16:23.320 --> 16:26.320 Another downside is that growl VM that does the compilation, 16:26.320 --> 16:32.320 will only compile to R64, so that is 64 bit ARM and X86 binary code. 16:32.320 --> 16:37.320 It will not specifically compile down to ARM 7HL 32 bit ARM code. 16:37.320 --> 16:43.320 And there are a lot of selfish OS devices out there, which are still running on 32 bit ARM chips. 16:43.320 --> 16:50.320 So unfortunately, as it stands, it's just not possible to apply this to 32 bit devices, which of course is very sad. 16:50.320 --> 16:55.320 It's a really unfortunate. It would be really nice to have the app work on those devices too. 16:55.320 --> 16:59.320 And then finally, there were some small patches needed to the extractor code to get it to work, 16:59.320 --> 17:03.320 because of the fact that, for example, reflection doesn't work with JARP-Pro VM. 17:03.320 --> 17:08.320 And thick, who did the selling to coffee implementation, actually push some changes upstream to 17:08.320 --> 17:13.320 new pipe, the new pipe repository, which the team accepted, and that worked really well. 17:13.320 --> 17:17.320 So that was really nice to see. So that was a good symbiosis. 17:17.320 --> 17:21.320 Yeah, so in general, it's a process that seems to work really well, 17:21.320 --> 17:24.320 but when you have this good separation. 17:24.320 --> 17:28.320 All right, so I'm just going to hand back now to Fabio to wrap things up. 17:28.320 --> 17:31.320 It's actually mine now. 17:35.320 --> 17:42.320 So yeah, thanks David for implementing the Save Usure as a port of the app, 17:42.320 --> 17:45.320 that was very interesting to hear. 17:46.320 --> 17:51.320 So to give a few information to conclude the talk, I would like to let you know that 17:51.320 --> 17:56.320 new pipe is not only a project, now it's also an association. 17:56.320 --> 18:01.320 And this association doesn't only want to promote new pipe itself, 18:01.320 --> 18:08.320 but it actually wants to promote more libre free access to media, 18:08.320 --> 18:12.320 like software that lets you access media more freely, 18:12.320 --> 18:15.320 such as applications, protocols, and so on. 18:15.320 --> 18:20.320 So five with only supported new pipe actually, because that's our baby, let's say, 18:20.320 --> 18:25.320 but we want to be a bit more helpful to the community in general. 18:25.320 --> 18:30.320 So if you have a project that has something to do with free media, 18:30.320 --> 18:34.320 and you think you would need some help, for example, 18:34.320 --> 18:38.320 in handling bureaucracy hiring or donations, 18:38.320 --> 18:43.320 you feel free to ask us, will I have already doing this for a new pipe? 18:43.320 --> 18:48.320 And if you want to join the association or contribute to new pipe, 18:48.320 --> 18:52.320 contribute code to new pipe for each free to join us. 18:52.320 --> 18:59.320 With this, I want to thank all of the contributors that have worked on new pipe throughout this last ten years, 18:59.320 --> 19:05.320 because new pipe is ten years old since a couple of months or something. 19:05.320 --> 19:11.320 Like a hardful, deep, hard thank you to all of the contributors. 19:11.320 --> 19:16.320 And yeah, you can find further links to our talk, to like the slides, 19:16.320 --> 19:22.320 and to everything we talked about in this talk by scanning the QR code on the right. 19:22.320 --> 19:30.320 And I think David wants to thank, again, the person that created all of the nice graphics. 19:30.320 --> 19:33.320 Yeah, thank you. Thank you, Fabier. Great. 19:33.320 --> 19:37.320 So thanks to Jerome Haymans, who did these amazing graphics. 19:37.320 --> 19:43.320 And Jerome actually, I think, live, live, drew the Devrim last year. 19:43.320 --> 19:48.320 So if you have a look on the message on, you can find all of the talks from last year, all of these in this format. 19:48.320 --> 19:51.320 So really, thanks. Thanks so much. 19:51.320 --> 20:02.320 Yeah, we're happy to take questions now. 20:02.320 --> 20:07.320 Thank you. 20:07.320 --> 20:11.320 Yeah, thank you. 20:11.320 --> 20:20.320 Would this also find a good starting point for, for example, going to touch our postmark to last? 20:20.320 --> 20:31.320 So regarding, yeah, so, can this approach be used for pointing your pipe to also wound the touch or other Linux devices? 20:31.320 --> 20:36.320 So there are already a couple of ports of new pipe to Linux. 20:36.320 --> 20:50.320 One of them uses an abstraction layer that was built specifically around new pipe, which basically takes all of the android API calls and turns them into Linux API calls. 20:50.320 --> 20:53.320 It doesn't work very well, but it kind of works. 20:53.320 --> 20:58.320 And this is just something that I use created and they put it on flat hub. 20:58.320 --> 21:01.320 So you can already download it for going to touch, I think. 21:01.320 --> 21:04.320 But don't expect to get a good experience out of it yet. 21:04.320 --> 21:12.320 And then another thing you can do is, well, you can just run it through way through it, or I don't remember the name, but like the android emulation software. 21:12.320 --> 21:17.320 We can talk about this outside, if you want. 21:18.320 --> 21:19.320 Yeah. 21:19.320 --> 21:27.320 How does the new pipe association consider the extraction of certain media from big platforms? 21:27.320 --> 21:31.320 And by as does that be considered at all? 21:31.320 --> 21:40.320 Whether new pipe association has considered the extraction of social media like Twitter, like Twitter. 21:40.320 --> 21:51.320 Okay, I see. So I think to this extent, there were other projects doing that in the past, but they have all been DMCA at some point or something like that. 21:51.320 --> 21:55.320 No, not DMCA, so the season disease did. 21:55.320 --> 22:05.320 Yeah, whether new pipe has had trouble with YouTube. 22:05.320 --> 22:11.320 Well, not really so far, which is fortunate, I don't know. 22:11.320 --> 22:22.320 So I mean, we have problems every say once a year when YouTube breaks changes the way the website works and then the up stops working and we have to push a hot fix release just like three days ago. 22:22.320 --> 22:35.320 But yeah, generally there's nothing too bad happening on the YouTube site where it was, for example, if YouTube were to start pushing for DRM because it's illegal to break DRM. 22:35.320 --> 22:46.320 And but so far, yeah, technically what we do is legal, so the hasn't haven't been backlash. 22:46.320 --> 22:51.320 Yeah. 22:51.320 --> 22:55.320 So the question was when will it work on landscape, it's a good question. 22:55.320 --> 22:58.320 So I guess you're not a disinterested party here, right? 22:58.320 --> 23:03.320 Because you developed the Voila ports of selfish rest for the Voila tablet, right? 23:03.320 --> 23:09.320 Yeah, there's a really good question. Not this week is the answer. 23:09.320 --> 23:13.320 But you have submitted an issue, I think, right? Someone submitted an issue, at least. 23:13.320 --> 23:16.320 So say the plan is for it to happen eventually, yeah. 23:16.320 --> 23:18.320 I mean, this week. 23:18.320 --> 23:21.320 I mean, this week. 23:21.320 --> 23:23.320 Right. 23:23.320 --> 23:26.320 The person, they're in the back. 23:26.320 --> 23:27.320 Yeah. 23:27.320 --> 23:34.320 So I have a question on, you know, Charles, but I'm just out of who you're seeing. 23:35.320 --> 23:51.320 So I think, I think then, so I guess there were two big reasons. 23:51.320 --> 23:53.320 Oh, sorry, I big one, thank you, yes. 23:53.320 --> 23:57.320 So the question was there are multiple Java version machines that are able to run. 23:57.320 --> 24:00.320 So why choose Growl VM specifically for this? 24:00.320 --> 24:02.320 And that's a really good question. 24:02.320 --> 24:06.320 I think there were two reasons. The first one was that thick, who I mentioned, had already 24:06.320 --> 24:12.320 developed this process that worked on selfish OS to build these binaries down into 24:12.320 --> 24:17.320 Executals books that would run and link against C++ really easily. 24:17.320 --> 24:22.320 So that was, that was main reason was that infrastructure was already there. 24:22.320 --> 24:28.320 And the second reason I suppose was that it feels, it feels more comfortable to have a native 24:28.320 --> 24:29.320 resource. 24:29.320 --> 24:35.320 It's quite a heavy addition to the system where it's actually Growl VM is quite light, relatively 24:35.320 --> 24:36.320 speaking, there's my experience. 24:36.320 --> 24:38.320 So you actually get quite a nice nimble. 24:38.320 --> 24:43.320 They're actually really big binaries, but apart from that, they're quite nice and 24:43.320 --> 24:44.320 contained. 24:44.320 --> 24:46.320 So I felt that was nice. 24:46.320 --> 24:48.320 Yeah. 24:48.320 --> 24:49.320 Yeah. 24:49.320 --> 24:55.320 I think one of the last questions in the middle of the time. 24:55.320 --> 24:56.320 Yeah. 24:56.320 --> 25:00.320 Now, how were you supposed to develop a certificate situation? 25:00.320 --> 25:04.320 What do you get to develop a certificate for Android? 25:04.320 --> 25:05.320 Yeah. 25:05.320 --> 25:06.320 Yeah. 25:06.320 --> 25:08.320 We are definitely aware of that problem. 25:08.320 --> 25:18.320 So as far as we understand, the terms of service, of the Goething Program, 25:18.320 --> 25:20.320 are not Google's terms of service. 25:20.320 --> 25:24.320 So technically, they might be different and they might allow us to get very 25:24.320 --> 25:31.320 fine, but it's still very bad that we are aware of the problem considering possibilities. 25:31.320 --> 25:37.320 I don't really have a better answer right now, but yeah. 25:37.320 --> 25:41.320 Thank you everyone for being here. 25:41.320 --> 25:44.320 We'll be outside and also to other members of the team. 25:44.320 --> 25:47.320 We'll be outside if you want to speak with us. 25:47.320 --> 25:48.320 And yeah. 25:48.320 --> 25:49.320 Thank you for your time. 25:49.320 --> 25:56.320 Thank you.