 Yeah, we are going to talk about application telemetry and user service. I mean, telemetry is something that came up in previous discussions on making this, okay, that means taking time. And I think we usually agree that that might be something good to have. For example, to answer questions like, how are applications actually used? In which environment are they used? Can we call X11 support? Because they're on the solution already. You don't know. Which Qt versions should we support? Yeah, we are making guesses. They are like, how quickly are our updates actually deployed? So which Qt versions should we still need to support? We don't have any data for this. Which features are actually used in the application? So is it worth to maintain our Qt 13 encryption support in Kmail? Or is that obsolete by now? We decide that based on gut feeling, but on actual data effects. Similar to a photographic workload. So how many folders does the average Kmail user have? If that's just a dozen. All the features we have to manage hundreds of folders, like favorites and search options. At least they probably should be off my default. This is typically something that is heavily influenced by the people working on it. They are biased, they are used to it. It would be nice to have some independent information to decide what to focus on, for development, for testing. For what we talk about, what we show people. That makes sense to highlight some new features that nobody is using. Let's focus on the stuff that is actually relevant. But 10-3 alone is not good enough. Because it can tell us misleading or incomplete information as well. If the result is a specific feature is unused in my application. Is that because the feature is broken, because nobody needs it, because it's obsolete. Or maybe people just don't know about it. Or they don't understand how to use it. Or it's actually good for it. From just telemetry data, we have no idea to decide this. I might leave this in the wrong direction. So what we can do about that is ask. Ask the users of our software. Or maybe even specifically those not using the feature while they are not using it. To see if they actually have their use case and don't understand it. We have done a few user services in the recent past. We kind of lack the means to properly execute this. We usually promote the service on the blog. Which is at the same time too wide. Impressing all kinds of people, not just the users of the software. The subset of all users. And to never, because it's biased towards the people following those media. The people actually using the software. So it would be nice to have to ask people inside the applications. So the users are even better at the specific subset of users. That we can address this way to participate in the service. But of course all the discussions we had in the past. Right for me to be the subject of price. Especially since the telemetry thing has been completely overdone. Particularly the mobile apps. Where even a simple flashlight app sends your address code to the server. Just people also. So of course we need to separate us from this. And of course we want something that addresses the entire privacy concerns. In a way that even people consider to enable us. And that I think involves dealing with a number of topics. One is transparency. So we need to make it very clear to use what data is essentially sent. In a way that the users can also understand. The next thing is control. So you want to be able to decide if it's the same plot. Or just a subset. So you need to find a way to actually select what you want to share. In a way that it's understandable. Another problem with this is unique identification. So it's this data that would allow somebody to track what I specifically have to integrate. Rather than just general information about the same acute version I'm using. That I'm willing to share. But like my exact meaning behavior of units. Probably not, especially not in the title. So we need to look at, yeah. What ways of identification are in the data. We can deal with that. And the fourth one, I think is four tables. Half is off by default. Explaining the use of why we need this. And why it's benefiting. And the first time to actually enable. So far there is a theory. That's all the nice things we want. That's usually as a discussion in the past. Now I wanted this program already. So I had the motivation to actually start building it. Not just needy. Especially when it comes to the requirements for what they don't want. How we present this to the user. This was done to get on the screen on publish. Something like that. But yeah. We haven't actually built something that tries to address those ideas in the client. And that's the key user framework. It's not technically a framework yet. But that's ideally very important. And that consists of basically three main elements. It's the library that goes into the application. The data. And interacting with the user of the application. There's a server component. The data is connected. And then there's analytics and management tools. Set up a product. You can update any one you try. Because I'm actually working on the data that comes in. Yeah. Originally this was built for the use of basic harmony. The use there since it worked with us. And already providing the first usability itself. Looking at how this works in a bit more detail. On the application side. We have a lot of data sources. Some built in. And the ability to have customer data sources. Which you can select from which one you actually want to use in the application. The data is submitted in a fixed interval that you add in the code. There is the service targeting. I mentioned that in a little more detail later. Then you have the ability to configure if you want to participate. And to what extent you want to participate. And there's a mechanism too. Because nobody would find this in the menu. So we try to nicely ask occasionally. If you don't have that in the menu yet. But also not at what the first variable you see then starting the application. So you have the time to actually try the application. And nicely ask rather than first dialogue is give us all the data. So that's the infrastructure we provide on the application side. For the data sources. As I mentioned we have some stuff built in. More common information on the environment. That might be generally useable. As well as some general application statistics. Like how often it's actually used. How long it'll keep using it. And in general we have those four categories. Which is also what we can select as a user. What kind of information you want to share. This is basically just a tool to pick from. This is not all my info. So you need to just add whatever sources you find useful. And of course you can add your own data sources to make specifics. Which we'll check in the application. And this is also used for the survey type. So the survey is basically just a URL to sort of form. Like we have always done it for surveys. Just the normal application. Well how you do it in the UI is up to you. For example we have the libraries. As a pop-up that asks you to fill in the survey. If you agree to do this. In the simplest case, just all the users get the survey presented to them. Prologially you can have the targeting information associated with this. Which is basically just a Boolean expression on the telemetry data. So the example there is multi-screen users on Windows. Just ask the data users or just the users of a specific feature. Or people that haven't used a specific feature yet. Anything that you can put in a Boolean expression. That has information that is in the telemetry data. An interesting question is how good is the data in a data business? Especially since we don't have the unit verification. So in order to come up with some actual numbers. We rely on the fixed submission interval. And then basically aggregate data in 7-day or 30-day intervals. Depending on what you have selected. Whether you see how all stuff changes over time. One thing you can't say with this is how many users can we have. Because it's all in, but we don't know what the participation ratio is. And we have no unique identification. So if there's two people using it. Automating in the middle of the week. For example, if it's the same person using it every week. You can't have that on the top. I think that's fine because the absolute number of users. That's useful to know for business and marketing reasons. But for development decision. The relative numbers are usually not the same. How many people are using a specific feature. That is in percentage right now. I need to know if it's 1,000 or 1 million. I need to know it's 80% right. So that's important feature. The consequences of making this all in. I think that is something we don't really know yet. We don't know how high the participation ratio is. We can't even measure that. And we don't know if it's giving us a bias. Selecting a specific user substrate. You might exclude the extremely privacy sensitive people. Who for privacy related applications. Like KDAOs, the crypto stuff. Would be a very important subset of users. You need to be careful on what you meet into the numbers. But in general it looks like you can actually get a lot of user information. That's all. How do we slope the control and transparency part. This is the configuration that we have in Gammaway. It's shipped in the library as a reference implementation. You can of course do that in various different ways. We also have a bunch of iterations on how to further improve that. But the key part for me is you have the list. There's all the shared information in a translated human understandable list basically. And if you're really curious and really want to understand what that actually means. You can search to be a more adjacent view. That shows you the request that's actually sent to the server. That is as much transparency as perhaps compared to... If you look at the whole Firefox list. They just ask you if you're okay with it. But they don't tell you anywhere in detail what they are actually tracking. So I think that is part of the improvement towards transparency. And hopefully it also prevents the user stuff. I'm fine with sharing this. There's nothing in there that's been assessed. I'll reuse this in your application. There's a simple class that you need to essentially be a feedback provider. You add a number of data sources to that. Existing also customer ones. You configure it. Also a few meters away. Which server to use. In which in turn all of you send... Then on the server side you send a product for your application. You tell it what data sources you expect. Which basically setting up a data risk schema. Yeah, then you wait. Because actually you actually see data. Your data release action needs to get out there. People need to use it for a while. So you encourage them. Then they kick in and ask them to actually enable it. Then they need to actually enable it. And then if you have a bit long submission interval. I mean two to three months down the line. You might start to get enough data to actually start to work with engines. So if you want to use that for kind of like a rapid feedback loop. Or like fine range changes in the application. That probably doesn't bring the long latency of that. I mean we don't know how quickly our point releases get rolled out. But basically it can be really cycles. I would expect six to twelve months for feedback loop. I mean that's still a big improvement. Compared to not having it at all. But it's not the magic solution that allows us super agile. It's going to change and you'll see the impact. You'll always see the impact of anything that happens in a half or four to six months. How you want to do it. So far this is only introduction used for camera range. Running on the point. Data infrastructures. And there we have less strict requirements. That's what we do with privacy and transparency. We don't have that compared to the AD standards where this is a commercial product. Which you get for free. We don't necessarily need to share the results with people. I think that's different for AD. So AD should have that on its own infrastructure. And ideally with more people having access to the data. Because that's the other part of transparency. You actually see what we're doing exactly. And you can verify that you're not doing anything illegal. I don't think we can make it completely open. Because then you can have a web service that is publicly available and publicly readable. And that just has way too much abuse risk. In a similar case. People need to restrict at least one side of the access. And it has to be in the access because we want everybody to find it. For example, just to be really comfortable. There's plenty of protection against vandalism or abuse in there. That might become necessary. Fingerprinting. So trying to identify users. Despite there being a very different idea. We actually have seen a few cases already with OpenGL. Stack information. Some of the versions of vendor information are incredibly detailed. You can get down to including your color revision. And the shower one of the providers stack that was built. With in one of these. That is actually a fairly unique combination. So we have a few iterations of trying to spread out this type of information. And reduce it to a subset that we actually want. Which also helps us because I don't care at which exact revision. The missile aspect we have. I only care if I can use OpenGL for three or four extensions. But that is an iterative process that we will discover in a lot of time. The combination of those data sources. It's actually too precise for the set as we get. So we come to this. In participation, as I said, we don't really know how high that is. But it seems likely that it is a very small ratio. So are there ways to encourage more people to participate. Without making this too annoying. Or going away from the top 10 questions. And I've seen that. Last time I was looking into using this. I want to get to a few more applications. I think I need to look into system-wide coordination. Because we don't want to have like any other app. I'm not puzzling you. I want to send data. Yes, the survey is still in. So you want to make sure this is. There's still enough time between those events. But that should be easy. Yeah, that's it. We have a box session on Tuesday. And we have a lot of specific data on user feedbacks. That provides what features you need. Is that something that we would consider as a user? What can we improve? And Plasma has one tomorrow. Specific data on how to use it. Yeah, that's it. I'm interested in the back end. You looked at solutions that make data analysis easy. I see there's a bit of PHP code. How do you store data at the moment? Yeah, that's something local for us as well. My research on what already existed was primarily on the application side. And in this++2 code, it's very little about this. I mean, mobile has tons of watches. The back end right now is PHP script. That's the stuff that makes me a database. So all the analytics is done in the management. And this is true. That's the main test of the application. I mean, that front end for this is some nice charts. It would be nice. But that's not something I'm efficient at. That's something. Originally it started something like that. And then I found Grafana. And the libraries were sold, except for text artists. But there are existing tools that we should be able to combine with this. Yeah, local point is not the same on the flight here already. That's definitely something new. And I would be very happy to get rid of this PHP server stuff. That process and accessibility. The interface is basically a single REST code. Here's a link to one of these. I mean, the JSON you saw in the dialogue was the data you're submitting. And the answer is, and this is the service I have for you. Find out if there's one that you use also might as well.