This video is part of Berkeley Math 115, an introductory undergraduate course on number theory, and will be mostly about the Gaussian integers and their relation to binary quadratic forms. So from the last few lectures, we've been looking at binary quadratic forms ax squared plus bxy plus cy squared, and considering which numbers n can be represented by them. And we were mostly taking n to be prime. For example, we can show that a number of prime can be written in the form x squared plus y squared if and only if p is equal to two or p is congruent to one modulo four. And what I want to do in this lecture is to consider more generally the case of what happens if n is not prime, which is a little bit more complicated. And for simplicity, I'm not going to talk about an arbitrary form. I'm just going to talk about the form x squared plus y squared. So we want to study which integers n can be represented as x squared plus y squared. And in how many ways can they be represented like this? Obviously, we're going to take n to be greater than or equal to zero. Otherwise, the question is kind of trivial. So this form has discriminant D, which is b squared minus four ac equal to minus four. So we know that n is represented primitively by some form of discriminant minus four. And all forms of discriminant minus four are equivalent to x squared plus y squared. So that's n is represented primitively by x squared plus y squared if and only if the discriminant D, which is minus four, is a square modulo four n. You remember there was this condition we had earlier about when is the number primitively represented by some form of discriminant D? Just remind you that primitive means x and y have to be co-prime. Well, in order to check this condition that D equals minus four is a square mod four n by the Chinese remainder thing, we just need to check the case n is some power of a prime because if something is a square modulo or prime powers dividing four n, then that would be okay. So we look at several cases. If p is congruent to three mod four, then there are no solutions because minus four or minus one is not a square modulo p for p three mod four. If p is congruent to one mod four, we are okay, we get some solutions. And if p is equal to two, it becomes a little bit more complicated because minus four is a square mod eight but not mod 16. So we can have n equal to two but not four because four times four is 16 and minus four is then not a square modulo four n. So we get the following condition for n to be primitively represented. So n is primitively represented by x squared plus y squared if and only if all primes dividing n are one or two modulo four and furthermore two squared does not divide the number n. What about non-primitive representations? Notice that there are plenty of numbers which have non-primitive representations but don't have primitive representations. For example, eight is equal to two squared plus two squared is a non-primitive representation of eight but you can't write n eight as a sum of two co-primes squares. So for non-primitive representations, x and y might have a common factor g.  So this occurs if n is a square times something with primitive representation. So this is equivalent to saying that all primes dividing n that are pre-mod for divide n to an even power. So to illustrate this, suppose I want to check whether say 3060 is divisible is a sum of two squares. You look at its prime factorization so it's two squared times three squared times five times 17 and now you pick out all the primes that are three mod four dividing it and you see there's only one prime that's three mod four and then you see it divides it to an even power. So this exponent is even and that means we are okay. So 3060 can be written as a sum of two squares although this will obviously be non-primitive because both of these squares will necessarily be divisible by this number three. So if we want to write a number as a sum of two squares how do we do it? Well we can observe that if m and m are both sums of two squares then so is m times n and there's a direct proof of this is short but somewhat mysterious. Suppose that m is equal to x1 squared plus y1 squared and suppose n is equal to x2 squared plus y2 squared then m times n is x1 squared plus y1 squared times x2 squared plus y2 squared which is equal to x1 x2 minus y1 y2 all squared plus x1 y2 plus x2 y1 all squared which you can check with a little bit of algebra and this certainly proves that the product of m and n is the sum of two squares but there's a big problem where does this funny-looking identity come from? I mean I just seem to have pulled it out of midair like a magician pulling a rabbit out of a hat or something. Well there's a good explanation for this identity as follows. It comes from Gaussian integers so what's a Gaussian integer? Well the Gaussian integer is something of the form m plus n i where m and n are integers and i squared is equal to minus one so these are complex numbers and we can draw a picture of the Gaussian integers so you know the complex numbers can be identified with the plane by mapping the complex number x plus i y to the point x y in the plane so the complex integers just form the so the Gaussian integers just form the lattice of all points in the plane with integer coordinates so that might be zero might be one two and the number i is here i plus one is there and so on so so this gives a very good picture of the Gaussian integers they look like the corners of a chess board and now we can explain this funny identity so m squared plus n squared if you've got a sum of two squares this means that m squared plus n squared actually factorizes in the Gaussian integers as n plus n i times m minus n i so sums of two squares mean that something in the Gaussian integers factorizes now suppose that m is equal to x one squared plus y one squared which is equal to x one plus i y one times x two plus times x one minus i y one and n is equal to x two squared plus y two squared which is x two plus i y two times x two minus i y two now we just multiply them together m times n is equal to x one plus i y one times and i'm going to take x two plus i y two and then i'm going to have x one minus i y one and x two minus i y two and now you notice that the product of the first two terms x one plus i y one times x two plus i y two is x one x two minus y one y two plus i times x one y two plus x two y one and this thing is the same except we change i to minus i and I'm not going to bother writing it all out and now we notice that if we take the square of this term here and add the square of this term here then we just get m times n because you know that we're just getting this number times its complex conjugate so if you look we've now reproduced this funny identity the mysterious term x one x two minus y one y two and so on come as the real and imaginary part of of this number here so calcium integers explain this strange identity and now we can use this to write numbers as a sum of two squares for example suppose I want to write seven six five zero zero um as a sum of two squares well I factorize it it's two squared times five cubed times three squared times 17 and now I write each of these primes dividing it as a sum of two squares and then since there are some of two squares I can write them as a product of Gaussian integers so two becomes one plus i squared times one minus i squared and five cubed becomes two plus i times two minus i or cubed because five is two squared plus one squared and three we can't write as um a sum of two squares so I just leave it as three squared and 17 we get um four plus i times four minus i and now what I want to do is I want to write this as m plus n i times m minus n i for some m and n and to do that I just pick out a sort of half of all these factors so I could take m to be say um um one plus i squared and then I have to pick out three of these well let's take three of the two plus i's so three times take two plus i cubed then I've got to pick out half of these three so I just get one three and then I pick out half of these and I could take the four plus i but let's take the four minus i just for a change and if I want I can put a unit in front of this like a power of i so m plus n i is going to be equal to this and if I multiply this out it turns out to be minus 114 minus 252 i so we get 76500 is equal to 114 squared plus 252 squared um so uh there's a similar thing you can do for sums of four squares that I just briefly mentioned so this is not about binary quadratic forms it's about quadratic forms and four variables and I'll just sketch it because it's a little bit off topic so I suppose I've got two integers that are sums of four squares um then their product is also a sum of four squares and I'm going to write this out because it's actually a bit messy and what I'll do is I'll just show you how you can find this expression for yourself so if I've got a sum of two squares I can write this as a plus bi times a minus bi if I've got a sum of four squares I can write this as a plus bi plus cj plus dk times a minus bi minus cj minus dk provided i, j and k satisfy the following relations first of all they must all have square equal to minus one and secondly they must actually anti-commute this means that i, j is minus j, i which is k, j, k is minus k, j which is i and k, i is minus i, k which is j and these are the famous Hamiltonian quaternions and if you write a, b, c, a squared plus c, b squared plus c squared plus d squared in this form and do the same for e squared plus f squared plus g squared plus h squared and then multiply a plus bi plus cj plus dk by e plus fi plus g, j plus h, k then you find a way of writing this product of two sums of four squares as another sum of four squares well if we can do that for two squares and for four squares you can ask can we do it for sums of three squares suppose I've got an integer which is the sum of three squares and another integer which is the sum of three squares is there some clever way of writing it as the sum of three squares and the answer is no we can write three is equal to one squared plus one squared plus one squared and five is equal to two squared plus one squared plus zero squared but three times five is fifteen and you can easily check this cannot be written as the sum of a square plus a square plus a square so so this is something funny that happens for sums of two squares and sums of four squares but there's no direct analog for sums of three squares and next we come to the following question suppose we have a prime which is common to one mod four and we want to find x and y such that p is equal to x squared plus y squared and we maybe we want to do this explicitly well there's a slow way we can just use trial and error so for example if we want to write 61 as a sum of two squares what we do is we pick the biggest square less than 61 and subtract it so we take 61 minus seven squared which is 12 and that's not a square well that's no good then we try the next biggest square 61 minus six squared and this is equal to 25 and that's really nice that's five squared so we've written 61 is equal to six squared plus five squared and this works just fine for small numbers up to a hundred or so um incidentally um the um um there's a uh people used to do mental calculation as a sort of way of um making money and one of the things mental calculators used to do as a trick was to write numbers as sums of four squares so here I've got a book on the mental calculators and one of the chapters is explicitly about writing numbers as sums of four squares and let me just magnify it so you can see it a bit better and you see there was some psychologist who was asked testing these calculator calculators and asking them to write say 15633 as a sum of four squares and it says you know Ruckel found the solution 125 squared plus six squared plus one squared plus one squared and eight seconds it sounds impressive um actually finding that in eight seconds was pretty easy for a competent calculator that the point is that 15663 is actually very slightly larger than five to the power of six which is 15625 and every mental calculator knows all the small powers of integers so we instantly noticed this was just equal to five to the power of six plus 38 so there you've got five to the power of six is 125 squared and then you've just got to write 38 as a sum of three squares and you know that that's not exactly difficult because notice it's 36 plus one plus one so you notice Ruckel was actually using this algorithm that I suggested that you subtract off the biggest square less than the number and then and then take a look at what's left um anyway um so that does actually give um a way of writing small primes as a sum of two squares but obviously it's not terribly good if you're trying to write a really big primes as sum of two squares you know imagine p has you know 50 or 100 digits so what we would like is a fast method for writing p as a sum of two squares well what we do is we first solve um x squared is congruent to minus one modulo p and you remember we had a fast probabilistic method of doing this what you do is you pick a random number g and you raise g to the power of p minus one over four and there's about a 50 chance that this will have square equal to minus one um so you just keep going until you find one that works okay so we have x squared plus one is equal to p times n for some integer n now we're going to factor this over the Gaussian so we've x plus i times x minus i is equal to p times n and p is going to have some factor y plus i z times y minus i z and how can we find y plus i z well um we can try finding it as the greatest common divisor of x plus i and p so we take the greatest common divisor of x plus i and our prime p in the Gaussian integers and uh with a very small amount of luck this greatest common divisor will be y plus i z for some y and z and then we will find p is equal to y plus i z times y minus i z so this will give us p is equal to y squared plus c squared so let's just see an example of how this works so um let's take p to be 13 and try and write it as a sum of two squares well I mean yeah this is kind of trivial it's three squared plus two squared but let's pretend we haven't noticed that so we first solve x squared is congruent to minus one mod 13 and the simplest solution to that is x equals five so we've got five squared plus one is 26 so we've got five squared plus one is equal to 13 times something 13 times two so five plus i times five minus i is equal to 13 times something so now what we do is we take the highest common divisor greatest common divisor five plus i and 13 well how do we do that well we just use Euclid's algorithm of course so we take 13 and divide it by five plus i and it's two times five plus i and we've got a remainder of three minus two i and then we take five plus i and we divide it by three minus two i and it's three minus two i times one plus i plus the remainder is now zero so Euclid's algorithm is finished and the greatest common divisor is three minus two i so um we find three squared plus two squared is indeed equal to 13 well there's one thing you may be a little bit suspicious of i said we were using Euclid's algorithm for Gaussian integers well how do we know we can do that so let's discuss Euclid for m plus ni we want Gaussian integers now for Euclid's algorithm to work we need division by remainder so given numbers a and b so a and b are now going to be Gaussian integers we want to write um um a is equal to b times q plus a remainder r with b where b is not equal to zero of course and we want r to be smaller than than b well what does smaller mean well we need to actually decide what it means for one Gaussian integer to be smaller than another and what we're going to say is is that the and we're going to measure the size of the Gaussian integer to be distance to the origin so if we've got a Gaussian integer r equals s plus i t the distance to the origin from point st to zero is just the square root of s squared plus t squared and instead of using the square root of s squared plus t squared let's use s squared plus t squared so let's use the square of the distance because that saves having to take square roots so what we want to do is we need to show we can divide one Gaussian integer by another and find a remainder that's smaller in the following sense so what we need to do is given a divided by b we need to write this as q plus r over b and now we want r over b to be of absolute distance the origin should be less than or equal to one so this is just the usual complex absolute value so we notice that this is some complex number and this is some Gaussian integer and this is some complex number of absolute value at most one so what we've got to do is to show given any complex number we can write it as a Gaussian integer plus something of absolute value at most one and if we can do that we will have a nice Euclidean algorithm and that's quite easy to see let's see it by drawing a picture of the Gaussian integers so here we have the Gaussian integer zero one one plus i i and so on remember they form a nice square lattice and now we're going to draw all complex numbers that are within distance one of a Gaussian integer so to do that we just draw a disc of radius one around every Gaussian integer and what we've got to do is to show that every complex number is inside one of these discs and that's kind of obvious um i mean um you know you can just see that these discs of radius one are obviously covering the complex plane so um you know if you've got some number q it's going to be inside one of these discs it may be inside more than one of these discs so the when we write a over b equals q plus um some remainder r over b this number q isn't necessarily unique if for instance if if sorry if if a over b was here for example we would take q to be this number one or we could take it as one minus i and r over b is going to be the distance from this is going to be the vector from this this Gaussian integer q to our number a over b so we do in fact have a nice Euclidean algorithm for Gaussian integers and can copy the usual algorithm for finding greatest common divisors there's another nice property Euclide algorithm actually implies the Gaussian integers have unique factorization so we can define what a Gaussian prime is it's one that you can't um write as a product of Gaussian numbers that aren't units for example five is not a prime in the Gaussian integers because we can write as two plus i times two minus i but anyway since we've got Euclide algorithm we can we can just copy the usual proof that the integers have unique factorization and we find the Gaussian integers have unique factorization um so i'm going to give another application of the Gaussian integers um so we've discussed whether or not we can write n as a sum of two squares but now let's ask how many solutions to the equation x squared plus y squared equals n are there and you notice there can be several solutions for example we can write 65 is equal to 8 squared plus 1 squared well it's also 7 squared plus 4 squared so it's two quite different solutions so what does this mean well um he would try to write n is equal to x squared plus y squared so we're trying to write n is equal to x plus i y times x minus i y so this says we're trying to write n as a complex number times its complex conjugate complex conjugate just means you change i to minus i so let's write n is equal to 2 to the something 2 to the a times 3 to the b times 5 to the c times 7 to the d and so on so we're going to write its prime factorization and we want to write each of these as something plus i y times something minus i y now we notice 2 to the a can be written as 1 plus i to the a times 1 minus i to the a so we can pick out we need to pick out a of these factors 3 to the b well well all we can do is write that as 3 to the b 5 to the c we can write as 2 plus i to the c times 2 minus i to the c and 7 to the d we can just write as 7 to the d and so on so um now what we we have to do is we have to pick out half these factors so for 3 the only thing we can pick out is 3 to the b over 2 um here we can pick out 2 plus i to the something and we can also pick out 2 minus i to the c minus something so we notice there are c ways to do this and 7 of course all we can do is take 7 to the d over 2 2 you've got to be a little bit careful about you might think we can take 1 plus i to the something times 1 minus i to the a minus something and you might think there are a different ways of doing that the trouble is that 1 plus i and 1 minus i differ from each other by units um you you notice that 1 minus i times i is actually equal to 1 plus i so um there's really only one way up to units of um picking out factors from this we can just pick out 1 plus i to the a and we might get a unit so the units are 1 i minus 1 minus i so let's see how many different ways of doing this there are first of all for every prime that's 3 mod 4 there's only one way to write n like this for the prime 2 we always get a factor of 4 because we can pick one of these four units in front of it to mess around with and for every prime of the form 1 mod 4 so i should have put c plus 1 there we get um the exponent of the prime plus 1 ways of doing it so um so this tells us um how many solutions there are for writing n as x squared plus y squared what we do is we write n as a product of primes we check that all primes that are 3 mod 4 have an even exponent otherwise there are no solutions and then we take 4 times the product of 1 plus the exponent of the primes that are 1 mod 4 so let's do an example or two just to see um so let's for example do 65 which is 5 times 13 and just check this so this is 5 power of 1 times 13 to the power of 1 so we have predicted the number of solutions should be 4 times 1 plus 1 that's this exponent plus 1 times 1 plus 1 that's the other exponent plus 1 okay so let's try and find these 16 solutions well we've got 65 is equal to 8 squared plus 1 squared is equal to 7 squared plus 4 squared and you know there are no other ways of writing 65 as a sum of two squares um so we seem to have a contradiction we said there are 16 solutions and here there are definitely only two solutions what's gone wrong well it turns out that each of these is really eight different solutions because we can also write this as plus or minus eight squared plus plus or minus one squared so um that's really four solutions because there are two signs there and two signs there and we can also write them in the other order it's plus or minus one squared plus plus or minus eight squared so so this really corresponds to eight slightly different solutions you know that these are actually different complex numbers we have eight plus i eight minus i minus eight plus i and so on and similarly there's another eight there so we really do have 16 different ways of writing 65 as a sum of two squares um well that's um where the exponent is one let's just have a look at one where the exponent is larger so let's just look at the number of ways of writing five to the n as a sum of two squares so five to the one well five is equal to two plus i times two minus i um so we can write as two squared plus one squared and by twiddling around with signs and changing the order we see there are eight solutions which is four times one plus one as predicted now five squared we're predicting there should be four times two plus one which is 12 solutions and five squared is two plus i squared times two minus i squared and now we can pick out a factor of i so some power of i so there are four possibilities times well we can get two plus i squared or two plus i times two minus i two minus i squared and this is going to give us the following solutions we can write five squared is equal to three squared plus four squared or um um zero squared plus five squared and this gives us eight solutions if we twiddle around with signs and so on and this gives us four solutions notice that we get four rather than eight because if you change the sign of zero that doesn't actually make a whole lot of difference so again we get 12 solutions but what about five cubed well here we can have two plus i cubed two plus i squared times two minus i two minus plus i times two minus i squared or two minus i cubed and this is going to give us two plus 11 i 10 plus five i 10 minus five i and two minus 11 i so you notice we're getting the solutions that 125 which is five cubed can be two squared plus 11 squared or it can be 10 squared plus five squared or it can be 10 squared plus minus five squared or it can be 10 squared uh sorry um or it can be two squared plus minus 11 squared so again we get um 16 solutions um as as as predicted and five to the four is similar here um we can get two plus i to the four giving which is equal to minus seven plus 24 i or we can get two plus i cubed which gives us um um well it's going to be two plus i cubed times two minus i and that's just going to be two plus i squared times five and that that's going to give us um 15 squared plus 20 squared you notice that's really three squared plus four squared except we've multiplied it by five squared and and similarly we can get two plus i squared times two minus i squared which is going to give us um it's going to give us naught squared plus 25 squared and so on so you can check we get the right number of solutions um okay well you notice from this um that we're getting a lot of solutions of Pythagoras's equation z squared is x squared plus y squared so there we have five squared is three squared plus four squared which is the one everyone knows and here we have um 25 squared is equal to seven squared plus 24 squared um so what i'm going to do next lecture is to look in more detail at Pythagoras's equation x squared plus y squared equals z squared and um look at several um different methods of solving that


Alright, so folks are going to get started. I am going to introduce Kristin talking about introducing BuildStream, a distribution agnostic open integration tool. So let's give him a hand and say hi. Let me put this. Hi. So I've come to talk again about BuildStream. It's been a year and now it's time for the second talk. So last time I didn't go through this in the right order. So what is BuildStream, right? So before I start talking, what is this guy talking about, right? So what is it? So it's an integration tool. We're trying to call it an integration tool because we've been calling it a meta-build tool and nobody really knows what that means. So it's a tool which builds, but it's not make and it's not see-make. So it delegates builds to other systems and it puts it all together and you have an integration. It's an integration tool. BuildStream is a pipeline of file system data permutations. So it's completely abstract and it lets you run operations inside an isolated environment in a pipeline where elements have source inputs and dependency inputs and they create outputs. So the basic of it is you have file system data in, file system data out, and things that happen in between. Sandbox execution environment. So we guarantee that there's no host tool contamination or anything and everything happens inside a container. We do caching and sharing of build results. So if you have a lot of people building together, already built something, you don't have to build it. We'll download it if it exists and we reduce the amount of compiles on the developer laptop at least. And multi-purpose build instructions and metadata is to say that you can have a project that outputs various things with the same stack. So generally in BuildStream you're going to be working with a series of components and not just one component, but we have an example at the end with just one component and a way to distribute it, but you can basically have projects that have different outputs and using the same stack so you don't have to have various collections of build stories for your software. And it has a developer story, which is late in the discovery process. We found out that's actually the coolest thing that we do. Probably. So on to the show. So I'm going to introduce our BuildStream beaver. It was our youngest team member who we affectionately called Tristan because he's so bright and it's also his name who said that it should definitely be a beaver because a beaver builds things in a stream. So here I've launched an epiphany build but I can see that we really can't see this very well, which is unfortunate because I have a lot of these screenshots. You know, you can't see that, huh? Okay. Well, I'll have to explain as we go along. So what are our motivations for doing BuildStream? So I'm going to try to jump through this segment because it can be a lot of talking. So one of the things we wanted to do, of course, we want to save time. We're in automation. We're automating stuff. We want to reduce the amount of work that people are doing. So we want to kill cross-compilation because from what I've seen, there's a lot of developer hours in projects and these are really good developers that I've worked with in other projects and I'm like, what are you doing? They're spending their days writing these one-line patches and upstreaming these one-line patches to projects to make sure that they compile cross-upstream. And we think you only really need to cross-compile the tool chain and once you have a tool chain and you have a kernel, you can boot hardware and from there you can just native compile. So if you can do that and if we can provide a system that lets you do that, then we can save on all of those developer hours doing menial tasks and I'm sure they'd all love to be actually creating something fun instead, right? So smoke testing builds on new build host platform, some tooling which uses host tools a lot. They need to be vetted for a new distro so the new version of Ubuntu or the new version of Debian comes out. It's not supported by, say, Yachto or Build Root or something and you have to spend a month or something fixing the bugs and we don't want that either. Complicated setup. This more pertains to like historical build tools which have been invented like more than 20 years ago and we have to keep using them because everything depends on them but we end up like setting up OBS and these huge setups that are not easily repeatable setups but they work, they work well, right? But you can't just set it up on your laptop in five minutes and build something repeatable with that, right? Monolithic repositories of build metadata. This pertains to projects like Build Root. I don't know if probably everybody's distribution's dev room you all know about build tools, I'm sure. Build Root, Yachto, these kinds of projects which have metadata in the same repo for the whole stack from the runtime to your graphic stack and everything. What I've noticed is you have a lot of friction in integrating patches especially in the lower level of the stack or people generate a lot of breakage in the upper parts of this track by prematurely merging stuff in the lower level of the stack because upgrading GCC or upgrading G-Lib C has side effects which are forced upon the consumers, right? So we wanted to reduce friction and for that we have a feature which lets one build stream project depend on another build stream project so you can have completely separate projects maintained by separate groups and separate teams and higher level depending projects can pull in the changes when they're ready, test against them, report bugs back to the lower stack maintainers and such like this. We hope it's going to be a better workflow but we're putting it in action now and we're going to see how that works out for us this year. So yeah, we don't want tight coupling of build systems and distributions and distributions what I mean here is the payload, right? In a lot of cases, cross systems especially have a tendency of writing tools for the specific software that they're going to build and that makes it difficult to take a tool that has been made to make this distribution and use it to make a completely different distribution. So you're kind of stuck with certain versions and certain setups depending on the tools that you use and we didn't want that to creep in. Yeah, so what about the developers, right? So we generally think about in the integration crowd we think about the developers are those people who just like hack stuff and run it on their laptop, right? And then they send us a patch or they send us a new source RPM and we're supposed to integrate it and they said it's fixed, right? But they never tested it on the integrated system and we blamed them for it but it would have taken them all day to like get a rig and find out the process from building it on OBS, you know, finding the process for flashing it to a rig and doing it. We didn't really give them tools to make it easy for them so I think that we're blaming the wrong people here. Okay. So a little segment on what we're doing about these problems how we're tackling them so kill cross compilation, right? So for this we're we're looking into features which let the sandbox execute under a given machine architecture and we have an abstraction layer for that and it's probably coming in the next six months we might see something materialize here but it's designed for this and right now we only support native builds but we're going to do it, I promise. Yeah. So that will be just a way that your project can declare or a configuration option can say try to build this on that hardware and it may require that you run a virtual machine to provide an emulated environment on your own laptop or that you're connected to a build farm and you have real hardware or development boards to actually run the builds and they just act as slaves to the build process. No host tools. This is thanks to your builder who said we shouldn't have host tools and I said you're crazy but it makes a lot of sense. No host tools. We just cut a lot of problems at the bud if you can have a host tool on your computer there's no reason you cannot have the same host tool in an SDK or in a sysroute so everything is controlled this way. We track every hash of every binary input into the build and there's nothing left to chance by saying no host tools. Make it easy to run the production environment I kind of already covered this so the tool itself if it can run it's running something that should produce bit for bit if the source is ready to do bit for bit reproducible builds it should be doing bit for bit reproducible builds on any machine so the time it takes you to set it up is the time it takes you to set up a production environment. So reproducible and repeatable I've kind of been making a distinction here some people are telling me there's no distinction like emit but reproducible builds is getting your builds to be bit for bit repeatable so that every time you build it you get exactly the same output and you can raise your level of trust a lot in the things that are being built because you know things that are already tested and on the other side of the story is when you want to repeat this process 10 years from now and you have this definitions of everything that you want to build and how to deploy your appliance or whatever it is you're doing it's important to be able to actually repeat the setup of creating a build machine from scratch because well we want to keep our eyes on how repeatable the process is because we can't say right now what the world is going to be like in 10 years of course we'll want to see this along the way so we have processes and a way in place we have a technique in place that lets us cross compile a a base run time and kernel and boot that just to run a shell script without an init system or anything which will consume some build instructions that we've generated into a script which will let you at least bootstrap a foreign architectures machine to a point where it can at least run build stream and then you've completed the process and you can always do it again I'm going to run through this because I have a walk through for you instead so multi-purpose build metadata I create an app I have to choose if I'm going to build a flat pack I have to build it myself if I want to build a snap I have to build it myself if I want to build a Debian package or an RPM package usually somebody is going to do it for me but in any case it would be nice if I don't have to maintain like three different sub directories of my module to say well this is how my OSX bundle works and this is how my flat pack bundle works I just want one build instructions we want that so basically tools to debug inside a target environment you have to put tools into your runtime if you want to use them in your runtime but we have some interesting tools that I'm going to show off in this talk that cover that artifact sharing so I want to test GTK against the latest epiphany and webkit and see what side effects happen there I should be able to do it without rebuilding the whole world somebody's probably built it testing the changes okay fun so now I'm going to have to look at the screen here so when you write BST show oh my god okay let's just try to hold this right like can you see the you can't even really see the colors here right so we can see that there are colors you can see that there are colors but you know this is not helping so basically we're saying that all of these elements are cached these are cached in purple these are cache keys so basically they're a stamp they're abbreviated shaws which represent the inputs of a build which is our prediction of whether it should be bit for bit reproducible bit for bit exactly the same so this one is GST plugins bad has that shaw everything is built so I have a epiphany that's built and I want to hack on GTK so I'm going to open a GTK workspace here I'm saying GST workspace open and then the element GTK 3.BST and then a directory right so the GTK 3.BST is a file which defines how to build GTK and stuff about GTK and here I've basically checked it out at exactly the version that I was going to use to build according to this project data and now I have all the source code inside so just keep in mind that after doing this I've opened up emacs and I've reversed the GTK label angle so that by default it's at 180 degrees so labels should be upside down I won't go through that so I'm going to show it again and just see what is the result and hope that you can't really okay well this one is green it says buildable that's GTK and here waiting waiting waiting waiting here we have webkit here is waiting everything that depends on GTK basically says well it's ready to build and this is my pipeline this is what's going to have to happen if I run a build if I want to see epiphany with a new GTK I've got to build all that but I don't want to build webkit alright so let's try without strict mode strict mode is by default everything has to be built every reverse dependency has to be rebuilt when something changes which is what you would want in production builds but with without strict mode in place then we just say that I'm going to test something with the exact version of everything but I'm not necessarily going to rebuild against everything so I'm going to lose out in places where I need to do static linking for that I need to add extra sugar to my project to say well no I need to be rebuilt strictly every time because I consume static libraries but mostly this works in a Linux environment where everything is dynamic you can test so here what I wanted to show you and now that the lights are off you can see the cache keys it says cached for everything except for GTK which is buildable but the cache keys have changed color the dim ones are the weak cache keys they're calculated differently we're falling back to these ones we're going to use them and those ones won't be pushed upstream things that get rebuilt in this case GTK won't get pushed to a shared artifact cache because it's just a local workspace and this lets us just whip it up together so oh yeah I was going to build this but Buddy told me he had a fix in Gstreamer so I want to check that out and add this to my build first so for that I'm going to track right I'm going to track Gstreamer and we don't really see well but there's an info it says I found a new revision so basically inside the file which defines how to define how to build Gstreamer you have the upstream URL and you have a tracking branch and you have the commit shaw that you want to build so BST track will basically take the branch information and use it to derive a new commit shaw and say well let's update your project such that such that you're building the latest of this component or you can do this recursively or not so here I've done git diff and I can see this well there's this red mumbo jumbo which has gone away and some green fuzzy stuff which there commit shaws so can we build it so now we see before we go well now we're trying to build it right before we go we have this buildable which is also Gstreamer but it's also in non strict mode so we're going to build just two things and right now we have our cute UI who's clicking away here Sam really loves the UI and the colors so I'm going to try to sell it his name yeah we've got something pretty interesting it's just a little hack with the terminal ANSI escape sequences which lets us like reserve some lines and we have our rolling log which will just keep going and you can redirect that to a log file or something but while you're watching the build you have this which just sticks at the bottom and you have your different cues here so I've pulled no elements from upstream and there's three actually there's zero, two and zero red is failures right so you have your three cues and you can see the things are moving through the cues and we have counters to say okay what are we right now doing so we're basically scheduling everything that's going on here and we have a full timer so we've been going for one minute and twenty seconds on this slide alright not bad, not bad so I ought not to wait for it to build when it finishes build it will tell you yay we built and you know you don't need to know but what is interesting is that gstreamer finished compiling before GTK3 even got to make so GTK3 was running configure and gstreamer which switched to meson just just like speeded right through configure and like killed it in this race yeah so it looks like meson is a good idea after all so now I've built everything I've got my upside down labels I think and now we can run a shell right oh this is even worse oh my god well that was BST shell epiphany.bst right basically what we're doing here is we're taking all the different little builds that we have the different basically every artifact is like the make desk deer equals foo install output stuff and we have a deterministic staging order dictated by the dependencies of everything and we just whip them up into the same directory with hardlinks and we run some integration commands right so we update like gsetting schemas and stuff like font caches and things after staging everything we also do this before every build right so every build has exactly what you expected so here I launched epiphany from the shell right and you have your upside down loading here we don't render this with labels but we're online and we have this upside down text here right so we know that we did run epiphany with the gtk that we hacked to turn the labels upside down at least there's some problems which have been reported about like epiphany specifically it needs to access the web and in the regular testing shell environment we allow we don't unshare the namespaces or unshare the net or anything like this so we don't use a secure container environment but we still have to echo nameserver <IP_ADDRESS> into resolve.conf in order for it to work so there's some little tweaking, we're thinking maybe some client side configuration or project level configuration because this is how you can create a shell environment where my applications should run but that can use work it's better to go with a VM it's better to actually distribute what you're done right so you never know what's on the host anyway so pipelines build stream is elements and pipelines let's take a look at what some plausible pipelines could look like to give some idea what's going on so this one is generate an image so we're not going to do this but we thought of doing this right now in GNOME what we have for building GNOME components is we use a dbootstrap base which lets us just say ok I don't care about my system dependencies I just want them to be there and I want to try to build and run stuff so at least we have a specific version of we're using dbn testing and this is orchestrated outside of a build pipeline because you cannot really run dbootstrap or multistrap twice and expect to have the same binary result so we run it on a server continuously and when we add dependencies it gets re-executed and the result gets committed into an OS tree repo which is controllable so we have a couple of hacks like this to make sure we get policeable data into the pipeline so here we import from an OS tree repo and then we build stuff so we can import the base system and build stuff and then we can use a compose element a compose element is going to take what you want out of what you built and make one output which is usually a lot smaller than what you had when you just used everything that was in make install right so you want to decide do I want my debugging symbols do I want all the documentation and you can tweak your elements to say well this part should be in this domain you can hand hold all of this with glob patterns and such so once you have your compose element we send it to this x86 image element is basically a script that we have in BST external repository and this one does it basically does what WIC does from Yachto it was basically generally based on what it was doing so there's a lot of new there's well new maybe five or ten years recent enough options to file system tools like MKFS to allow you to generate images using the data that you have in a directory without ever becoming a root right so that in conjunction with a DOS partition and another user space utility and syslinux lets you splice partitions of an image into something that you can boot without needing a loopback mount or anything that you're not allowed to do on your on your user so that's one configuration this is another example of how we do flat packs and that's coming this week I think next week we were looking at a release last week the free desktop sdk project so basically this is how we would build the GNOME stack first we would import the free desktop which is already built it was previously built with Yachto plus flat pack builder for the 1.6 SDKs and runtimes we're going we're building them with build stream from the bootstrap up with the free desktop sdk project from the 1.8 here we just take the same build metadata that developers use on a day-to-day basis to build and test but we build it on top of this SDK and then we use similar compose things compose lets you we're going to like split out the locale extension of a flat pack I'm not sure how I think maybe a flat pack and knows what I'm talking about but you have like SDKs have different they have mounts of sorts you have locale, you have debug you have different things, split them out and here you just put some fairy dust which is like flatpack.meta or something which informs flatpack runtime what to do about portals and stuff permissions and such metadata that flatpack would understand but I have no idea and then you get a checkout that you can make an os3 repo and deploy it as a flatpack for today we have a demo it's not what I wanted at least it's half of what I wanted so in this demo we can see it a little bit better here so in this demo I'm going to build glade on top of a very specific Debian base and then I'm going to generate a glade package in that environment targeting the Debian version which I staged using Debian tooling which was staged as part of that import process from os3 so here we have a bit of a sample of what BST files look like this is basically an import element which says let's bring stuff into the pipeline using an os3 source at a given URL with a GPG key that I'm revisioning locally to check my download from that os3 repo that it's saying it's signed by the people I expect and we're using AMD64 and we have a ref alright then we have to do this something that's actually a bit more freaky because so the import we've imported that multi-strap thing but the multi-strap thing it doesn't configure because it's running on ARCH64 and it does like a bunch of different architectures so when you get onto a host that you know is going to build we stage it all and we run dpackage configure and we add a little bit to that to remove stuff that we don't want and to tiptoe around it's possibly failing without being really root and since we have the install root here that indicates that this script element so it's just a script element which runs commands it stages this it runs some commands and because it said the install root is slash the entire output is the entire sys root and it's just basically done a transformation on it and the output is what we want because that's an environment we know is safe to execute in so then when we build Glade this is an auto tools element because it's nice and slow unlike meson so it adds padding to your build time in the demo when you have like minutes to burn in the conference yeah so basically we just say I depend on this sys root which I just previously configured and stage me these sources so this is the sources I want to build I'm using an alias to like http dot dot dot slash gnome glade.git right and here we have some interesting stuff the public data so basically everything we've seen so far is either core build stream format or configurations that are declared by the plugins which implement them and that's all validated so if ever you specify a typo or invalid value or something you're going to get an early abort but the public data is completely free form and what's special about it is in a pipeline such as this every element can see the public data on all of the elements it depends on right so a given element can say this is some metadata that a later element can consume and it doesn't have to be bound to any API constraints it's rather free form so this is actually informing this element the d-package deploy element what are the things you're going to need to know to be able to make a package out of me right then we move to this is a most of this happens in python in a custom element so we don't see a lot of script here but basically this one the d-package deploy element is going to take the input artifact so that's part of the d-package deploy's custom element configuration which says tell me what you want me to package tell me what part of my dependencies is the base because he has to decide well I'm going to stage all of this dependencies and try to run on it right surf on it and this other dependency I'm not putting it there I'm just going to build it so it puts it in different parts of the sandbox and one of them is the execution environment and the other one is going to do something with it's going to package something yes so I have a feeling that we might be able to see a bit better here right better just okay what do we have here so this is the project right so we have that key which verifies the input and here we have our elements and we have our cached elements nice and big and they're already built so I can't really build them for you right now maybe maybe I could we'll try that after if we have time so look at I'm going to check out that last element from the slides we're going to check it out in a location and that is there and what this the package element did it just went through the different domains that we use for there's different categories for stuff and we just said well I'm going to take everything in the runtime package and put it in a runtime it's really stupid and straightforward but it can be tweaked and those categories of files those split domains as we call them can also be configured so you can do more fancy stuff and it's a work in progress which is why it doesn't install cleanly on my OS so I don't have a glade right ah and I'm doing force all let me see what I think what happened when I did without force all it said you don't have yeah so architecture we didn't sort that out and there's also missing description need some description in the metadata huh that's just a warning okay any was a bad mistake you know um there's a well that's really bad don't do this right you know it it works right except that the display is very very small but basically you can you can use it and it's running on my host against my host libraries and what's interesting is that I'm running Debian stretch and that was so yeah it's not I should have built it against Debian stretch but I had only a testing run time available at the moment so but what's interesting is you can target specific versions and you can develop your package for fedora or for Debian or for whichever on your gen 2 machine and actually the host should never be relevant in what you're building right because your host is always just a moving target so I think that's pretty cool mm-hmm and right now we're getting into the soon we're going to have Q&A but should I let's see um now we said architecture AMD64 right yes huh okay so I'm curious to see if I kill the warning with this and oh my okay so we failed our 80 character terminal with Sam I'm sorry this is horrible outrageous no no no no this is horrible I know I know there we go but then nobody can see anymore oh ahh yeah okay okay okay and that should be the same yeah okay so it's time for the Spanish Inquisition yes so um when you're building um binary packages for um Debian here Dora or whatever am I right in saying that you're skipping straight past the source package stage yes I'm going directly to essentially a glorified table so you have a Debian packet a Debian a .dev here that has never had a .dev city or in Dora land you'd have RPMs that there just has never been a corresponding SRPM yes basically we're yes so we want to use the same build instructions right and we want to treat the packaging systems as only a packaging system and not a build system right so these packages can only ever be like released uploaded whatever to a distribution that has like made a decision that this is an okay way of working yes yes yes I had a question about I realized this is all generic but in practice the compose stage and the image stage once you have caching of the artifacts those stages tend to be quite long and take a lot of time especially if you were going to build source package unpack that and sort of have all of this package could you comment on how we could improve those stages so you actually get the minimal amount of work for these tiny changes okay so or just explain in practice how you what happens in those stages for example well unpack all the oh in the beginning to create a system to build on top of no no in the compose and image building stage the last two stages you had the bootable system so there in that example we don't use packages at all right but there is another project that we have which does accept it's not using build stream yet and we have something similar which creates the packages for our p.m. using dash bb skip the build steps and it will use rpm install dash dash sys root into a place and it will do that but that's especially because it was for an organization which was using rpm and using me go image creator for the one package I guess what I'm looking for is can you start with all the stuff that hasn't changed like would you integrate something like to get the minimal amount of work to change create a root call system based on what you there is similar those kind of changes on that file level that's very difficult to do yeah that's on the file level we don't have that really no it's one shot compose for compose it's very doable and for the image constructing the image is very tricky because you have partitions and you need to splice them but yeah it's difficult anybody else yes how do you get your initial bootstrap environment so like enough compiler to compile the rest of your system and that kind of thing so Havia and Adam are working on the free desktop sdk project and they they are doing a project which does the bootstrap and I'm not sure where they are with it yet but basically yeah I'm just not sure about what's the input going into the cycle but it should be circular at this time so you basically have glibc gcc busybox and I think you need GNU sed to get through the build of gcc so that's completely off of an alter buildstream is it well buildstream has been doing these bootstraps since the beginning because it's very important to us to know that we can right but yes that's a separate project yeah the way it works is the first time we built it it was from a free desktop sdk 1.6 that we were importing I believe and now that we've built it once we commit it and then and the first stage is cross so the first stage you generate an output with a target and you never execute on the build any of the binaries that you generate but then you can import that on a foreign architecture and continue the build from there yes how many how many projects have been like imported to have the metadata and rebuildable any of the gtk so during the past like since guatec we've had a system going on where we were building from conversions of jh build so as far as gnome goes there's everything that was in jh build sends the apps because release team wants to make the distinction where apps go into flatpacks and only core gets built separately so those are currently being built with build stream and where havee should get ci online next week so that we have auto builds asides from that other projects which cannot be spoken of but yeah I'm hoping to get to a point where I can make flatpacks of glade and like have it myself and we're gonna talk with alexander larson about having support in flat hub as well yeah iñacio bsd that's what you mean like not other architectures other platforms yeah so we have a unix backend because right now by default on linux we use bubble wrap for the containers and we use os tree for the artifact cache because there are optimal solutions for the problem and we have a lot of unices out there which just don't have that and doesn't really make sense to like make os tree supported I don't think that's gonna fly for every different platform like unix so we have a unix platform backend which requires root and you do a charoot and you use tar balls instead we have somebody I forget his name last week came in and started testing building gnome on bsd and he's got some some like hack patches that we can inspect and use it to fix it for bsd but we want to make better platforms for specific targets using the technologies which exist on those targets windows is a long time coming I think it's not next week thank you very much that was our last question


Random forests, RFs, are a popular machine learning algorithm used for classification tasks. A case study was conducted to analyze the effects of various input data characteristics on RF classifications. The study found that high-dimensional datasets should be reduced before use in order to reduce the number of correlated variables. Additionally, it was found that the size of the training dataset has a significant effect on the accuracy of the RF model. Furthermore, the study showed that the training data should be randomized or created in a way that reflects the true class proportions in the landscape in order to obtain accurate predictions. Finally, the study demonstrated that spatial autocorrelation can lead to inflated estimates of RF out-of-bag classification accuracy, thus highlighting the importance of reducing this effect. This article was authored by Kareem Millard and Murray Richardson.


All right, welcome to the July 19th 2023 Aries working group call. We've got a full agenda marketing update. From Alex and Helen overview of areas VCX is the highlight today we've got the team here Patrick has joining us to give an overview of areas VCX where a ton has been happening lately, lots and lots of stuff going on. And then if we have time we'll have a status of the SDK discussion at the, at the end, and again only if we have time for that one. Reminder that this is a Linux foundation and hyper ledger foundation meeting so the Linux antitrust policy is in effect which is on your screen, and the hyper ledger code of conduct is in effect let's be good to one another. Feel free to join the attendees list. I put the link to this page into the chat. If you jump in. Please add your name to to the attendees list. Is there anyone new to the meeting. We, if you are new we welcome people to step up to the microphone and sort of say why you're here and, and what your interest is in and how we can help you get oriented in the areas community. No takers on that. All right. As far as announcements. If anyone has announcements I'm going to start with acopi we've got a release is zero nine zero pending we've got one more PR to go into that it will have a new release of credits which has is the an on credits. Which has some performance improvements and some fixes in an on credits and seal signature libraries that's the big thing going into that. But there's a number of other things including we're moving to Python 3.9 with this release. So the base will all be 3.9 in the in the various images and so on that are released so that's the news happening in acopi. Any other announcements from any of the other groups. Right. Alex. You've got the mic. Do you have a do you want to share. Yeah, I'll just share. Thank you. Okay, folks. I'm five minutes. I want to give you an update on two things that I've been working on a survey we set around that many may have seen about areas comes and then an update description of what areas is that we want to put on to the wiki as a starting point ASAP. So rather than the great detail I'm going to go through them briefly right now, share them on the screen but both links are in the meeting notes. So please review them at your leisure. They should be very in line with what we've been discussing last few weeks has no surprises so on that basis what I'd like to propose is that we'll give it a couple of days people to digest and follow up if they need to. Otherwise we can do an update to the wiki landing page with new description on the basis that we can always iterate it and make it better going forwards. So it's not set in stone it's just much better than what we've got right now. Yes, so on that base I just goes as briefly. There's a presentation link again is in the slide notes in the meeting notes. We got 16 responses from the survey we put together. We probably publicize on the high pressure discord. I'm here in the working group within a few organizations as well. And the summary of the results is mostly in line. You can go into these are these questions that you're on time but mostly in line with what we thought before with a couple of interesting insights. People didn't really care about areas being front and center saying he don't require blockchain that wasn't important to people, both in the dev and exec site. And there wasn't massively strong support for being shouting from the rooftops about creating wallets and agents being the thing you have to say upfront. Of course you can do that but it's not as important as we thought it might have been the rest of it pretty much in line with what we thought like privacy preserving everything else. These are the business results and these are the developer results on the next slide so you can even look at those as you wish. We got some great suggestions of other things you might want to mention in our description from government level identity and KYC very critical or cryptography status and whether it's better than so forth conform with his standards and great recommendations from people. And we also got a big laundry list of starting materials. Lots of courses repose videos that we're going to put into that wiki page as well as starting points. People coming to this fresh. Here along the line with what Steve just said as soon as we can get update the hyper ledger period pages by Aries the better. And we're going to update that when we can because they're doing a site refresh now and was going to update the REITME file for the main Aries GitHub page as well. So with that said, again, I'll just give you a quick summary. We've got these two descriptions in the other document that links also in the meeting notes in line with those survey results. This is building on the draft we had before. And with a few changes and a bit more scannable and a few things deep prioritize to make it clearer. So on the first page isn't it is a general overview and this is the one that will probably form the basis of the wiki page. And then probably to be adapted for the hyper ledger areas for the hyper ledger site is this higher level, more exact focus with less terminology. And we can have this in our back pocket for future users anyway. But there's this version as well which is the same as the top one but less techy. That reaches my time so but yeah go ahead Steven and welcome any initial thoughts right now. This looks great. Yeah, I think we've got a good starting point and again, I would suggest if anyone's got concerns about prioritization what I'd like to recommend is that. Let's get this up I mean if you feel as a showstopper please say because this is a community effort but what I'd suggest is let's get something improved. And if we need to iterate it. By all means reach out to handle myself our email addresses are on the meeting notes. I'll also chime in here that we, I'm still putting together the list of links that folks sent, which is fantastic there we probably got at least have a couple dozen at least. But if there are any links to white papers reports blogs. You know your company might have a podcast or whatever anyways any any type of links that you think are helpful and beneficial to new folks in that that approach areas. Please send them my way because we would love to have a, you know, a quasi comprehensive thriving list of community sourced places for people to read more and learn more and see the growth of the community. Absolutely. Awesome. Thanks so much. Yeah, thank you Steven thank you Patrick for a short inter interjection there and any feedback send it away much appreciated. Alright, if no one has any other comments let's go to areas BCX. Let's get an introduction to that for those that haven't looked at it in a while and learn about it and hear from the team so over to you Patrick. Thank you thank you. Alright, I'll share my screen and report some sort of improvised presentation I like to draw it all so I just skate something together. Right. It's very flexible. All right, let me maybe turn off the camera for now. Okay, so hello everyone. My name is Patrick stash I'm one of the maintenance of maintainers of areas BCX and I came came here, we me and the team came here today to talk a little bit about you know what it is who we are and why we are doing what we're doing. So, starting with some general info then we'll go into a component overview from mainly from perspective of where we are currently and where we are going can maybe where we've been before. So that kind of should give you idea of the trajectory of the project not only the you know status quo at the moment but also where we are headed from where and so I'll talk about talk a bit about the components we have deprecated components which are sort of stable new components we created from the scratch and stuff we are planning to do. So, some, some more intro here. So, first like elementary question what is actually areas BCX so. So the general approach we are like philosophy we, we take is that we rather consider ourselves as a library rather than framework so it's not that kind of a batteries included approach. We are already ready we are trying to provide the building blocks for creating areas and also known areas applications. So we have a sort of a. Obviously the kind of first class citizen right now is the library itself implementing the areas protocols, but also the repository contains a lot more is also a set of areas and supporting components written in the rust like the resolver the parser. This is a project maintained by three people representing ups I just saw the Frequent Bank, me included, and George Mulhern as an independent contributor. We have him on a call right now as well, we have everyone on the call I believe. So, and then maybe the question is why are we here now suddenly we've been kind of working in the shadows for a long time didn't really engage a lot with community didn't join these calls. Thank you very much. So, one of the reasons just just from the nature of, I guess evolution, the library and experience of ourselves as developers as well. So, some of you might know that the project was fork originally from something called lead BCX, which was part of living the developed by every name. So just from nature of like having different philosophy before different priorities. Given what we are we're trying to achieve.  We wanted to do like a bunch of cleaning and trying to trim it into our, you know, our kind of shape, we wanted to have. So for a long time. We didn't really feel confident to like invite people and engage like widely, because there was lots of, you know, our own work, we felt like we need to do first. And it was also difficult to onboard people, the setup to get the whole thing running was quite difficult. And maybe for for sometime in the past we didn't even have like clear understanding of our identity like who are actually who we actually are in the framework, should we try to build things conveniently batteries include kind of way, should are we trying to build an agent eventually, you know, we were not sure what we are, and this kind of shaped over time and we understood that we are building as I mentioned rather like components and library than like agent or or framework even so and also additionally, we are looking to kind of start just in general we would like to engage more widely with the community perhaps have more contribution outside of areas we see as repo, and also, given, you know, given the previous points, we feel more confident welcoming new contributors who would like to, you know, work with us and, and, and create something there's there's plenty of work. So, I will move to the component overview, but I just thought maybe it's good idea to stop for a second and just like give us space for a shorter. If there's any questions, although there will be time for Q amp a afterwards so, but anyway, if there's any comments or thoughts before I move on. Now it's, now is the time. I'll ask one quick question. The series of agnostic supporting rust components. Do you see it as a good idea that things like the did resolve or I did parser would would be useful to use in other areas frameworks. We'd be looking at replacing a did resolver and occupy say with the did resolver component that you have. I believe it will be a good idea that's that's eventually our goal to basically not only build like areas library, but there's lots of stuff we just like the did resolve right which is really independent from areas and can be just used anywhere so it will be pretty not to try to modularize it so that's what we did and well if you know if somebody uses will be more than happy because then more people will be incentivized to make it awesome and great and reliable and safe. So, you know, it will be amazing if, if, if, as I mentioned last point if there's new contributors will decide to let's say even just reuse some components. And then we would have, you know, a reason to work together. So that would be great. Thank you. Any, any other thoughts or comments. Yes, I have a question Patrick over to here. We've been speaking for a couple of weeks on the discord channel. I just one generic question here and I have some follow up question but we can wait till the end. Why rust. What are the advantages of this programming language and what would you tell someone who's thinking about maybe going down this route learning rust to get into the, into the space of contributing into areas VCX. What would you tell that person. Yeah. So, so historically like we had just like a reasons to go with the VCX and improve it over time but, but now, like, you know, I guess additional reasons like emerge for us or like strengthen our convictions mainly the ease to integrate with other rust components, given that most of the areas, you know, basic components are written in rust we find that it, it makes sense and it's easier and safer to just, you know, stay in the same ecosystem. Use the advantage of all the typing and all the good stuff done in this, you know, core core libraries. And well, in general, you know, like the typically pitched like rust advantages about the safety typing and like, you know, costless abstractions. Well, we find it like, you know, it's, it's, it's, it has also advantages to stay in the ecosystem and basically implementing areas in the rust, we can propagate the advantage to possibly other applications. Whether it's, you know, mobile or whatever rust in, you know, every infrastructure you want to build issue or verify mediator. We are giving that option to stay in that ecosystem, you know, not having to reimplement areas like it's there. So now it's possible to actually build issue or verify mediator, or whatever else, you know, from these rust components. So we like to consume this, this, this components natively and we kind of want to propagate these advantages further to other applications and see see thriving. Okay, thank you. All right, I'll move, move on, and we can get back to some questions at the end so I basically only one more slide left. So component overview. Maximize this maybe. All right, so this can go away. So here I wrote, draw like a kind of high level overview of all the components are the really holistic overview of the repo. It's detailed and detailed in some parts, but I find those, those important. So for the like, you know, coloring schema. So there's like the red ones are the procated blue one are somewhat stable doesn't mean there's no changes but I know they've been around for a long time and maybe there wasn't so many changes recently. And then we have like new components of green which are pretty much written from scratch like really new new green filled components. Then we have yellow which is in progress. There's a few of them. And then orange is kind of on the roadmap, you know, or something we are thinking about or possibly planning or hoping that somebody else might do it maybe. So, let's let's dive into it so I'll start with like the, the main part of the core components where we have you know the areas VCS trade itself so this is for us kind of a first class citizen. So this is the integration layer of all sub components we have, and it's a main building block for an, and you know, a third party application which wants to use areas protocols for something. And so this is purely rust. So you would consume areas VCS from another rust project. So VCS itself. It's as you see it's using like a number of sub components there's some deprecated the dog. And but we have a whole bunch of new crates actually written from scratch. The rewritten are like every messages data models from scratch. We have recently wrote a deity resolver, the, you know, kind of a deep dock data model and builder, you know, and all the stuff you might want to have to kind of work with the and then some, some deep methods we have the itself the web the peer hopefully like, I don't know the state of the dindy but they'll be coming as soon as it's possible to implement. Yeah, and then we have then we have as you see I split it out areas VCS credit kind of actually into two sections. So we have like a kind of old person, a stable, and then we are now in progress of essentially rewriting our state machines in a better, more testable and reliable way to make sure that are, you know, there are, they don't really contain much like contain as little IO as possible. And we are starting now we did exchange protocol actually with this approach. So we'll be adding more, you know, we'll be applying kind of, we are in a pioneering stage where we are kind of discovering how to write this every state machines in a better way and so the first one is kind of the most difficult just still learning. And then we'll kind of reapply the same approach and all the other ones. Then we have also, I would like to mention this whole big green blob of components here, which is also written from scratch recently. That's about interfaces to to the ledger. So we have like generic, like general interfaces for simply reading and writing to like to writing on on credits structures, and then separate interfaces, which are specific to Indy. And then what I really like are the sub sub sub components underneath that. So that for example we have like just transaction submit or interface which can be implant for which we actually have I believe three different implementations. So we can submit your transactions using Indy VDR, or we can easily be in the, or we can even use VDR proxy. So this is super cool when you want to actually run, you know, some kind of issue, some kind of issue or very far service in club in restricted cloud environment where you might not be able to use zero and cube because of security guys and stuff like that. So, so then in that case you can, you can use VDR proxy to kind of offload, you know that burden of dealing with zero and Q, you know, from your issue or very far service and you don't, you don't have to deal with those security compliance, you have offloaded somewhere else, maybe two different VPC or something. So I really like this one.  So we have like separate signer for transactions, which is basically only only you only need that if you are right, if you're ever writing on the in the ledger and some response parser which are picked from from actually living the as we found that VDR didn't have modeled like a data model for ledger responses. So we found this piece of liberty pretty useful. Well, and underneath that, we have like our the engine of this whole thing, which is like the ledger implementation and credit implementation and wallet implementation. As you can see we are now deprecating VDR tools, aka Libindi ledger client implementation. Next with an uncreds you are deprecating VDR tools implementation VDR tools, especially been the implementation of uncreds in favor of credits which we have just implemented recently including migration from VDR tools to credits. And now we are kind of slightly struggling to move on to unencreds RS it's kind of one of our challenges at the moment. And then with what we are pretty actually pretty happy with VDR tools, aka Libindi implementation of the wallets, which provides my SQL and SQLite implementations. The plan kind of is this is an orange color, which stands for like roadmap or plant. We are definitely thinking of implementing the storage interface with with Ascar as well. And then I actually move a layer up which I skipped initially I started from core components and went down to the to the underlying engine, but looking up, we also have like FFI layer on top of that and some application layer. So for the FFI, historically, there was something called libvcx and that used to be actually the main value proposition in the old times when when this code resided in the SDK, the libvcx provided a way for people to build mobile applications. Now that's being deprecated as the approach itself how to do these FFI is kind of outdated at the moment and there are better alternatives to do this. So instead, we are and we are kind of in a prototyping like initial phases of building alternative to libvcx so people will be able to build mobile applications using, you know, basically providing areas V6 APIs to Java, you know, to Android and iOS. So we have we have started Hyperledger mentorship project which got approved and we have a mentee right now we are mentoring working on uni FFI based wrapper around areas Vcx, which auto generates, which we will, which will be, or is auto generating Kotlin and Swift wrapper wrappers. So it should be a lot, a lot easier to maintain and should be a lot more reliable safer, all the good stuff. Now moving to the right side, this is, this is, I mean technically these two are equivalent it just like some these two boxes, FFI and applications, it just some rust libraries or applications, which consume areas Vcx as a, you know, the kind of a main trade. And so, but the difference here is in the application section I put here projects which are like natively in Rust and will stay in Rust. So we have, we have within the repo we have something called areas Vcx agent which is like really simple areas agent library, and it makes it a little bit easier to build the agent in Rust, it provides persistence and some, some, you know, like default processing of messages, which you would like, which is like likely desiring like agent implementation, and then on top of that we have implemented an example for areas agent test harness, which is like running. By the way, here I have like the latest result I found, this is the, you know, Vcx interrupt with the other frameworks we have like this and coverage with acupy. We have coverage with AFJ, not full. I think some tests are like skipped, or maybe something is failing, we'll have to take a look at that. We have obviously good coverage with ourselves. There's other frameworks. We don't have coverage, but they also don't have coverage with other ones, for example, the .NET or AFJ go, they don't have actually much coverage with the other frameworks either. So we try to cover the kind of the main, we consider main ones, the acupy and AFJ at the moment, lots of big communities around these. So that's what we kind of care about the most right now in terms of the interrupt. And yeah, moving back to the other, moving forward to the other applications here. So we have another mentorship project under Hyperledger, which is Aries Mediator, you know, or Ditko Mediator. So it's just like standard stuff, pickup protocol 2.0, you know, it's kind of experimental. I know there's a talk on Discord about mediators and we are not very active there, just kind of trying stuff on our own right now, you know, and see where we get, I guess. And maybe, you know, we can, if we run into challenges or some like learnings, we can share that, but right now it's in a very initial stages. So we don't really have like much to share yet. And then in an orange color as a kind of a plant or, you know, thought about at least is some sort of enterprise issue very far. You know, it seems like a natural evolution that lots of people is interested in, in, I would say, FFI people who come into Aries BCX are often asking about are often looking to build native applications. They're asking Libby CX, we tell them that it's deprecated that there's UniFFI, you know, it's kind of hard choice. It's kind of difficult moment right now, because like this is deprecated and this is not yet mature. So it's kind of either build something kind of on your own or you contribute here or you just stay patient. But in terms of like on the other underside, you know, of the of the issue and very far, you know, given that it's kind of crucial service I would find it as a natural evolution that we want to get here and have, you know, take advantage of all the performance and the safety and in like issue very far landscape as well. So, yeah, this is kind of what it is, what do we do, and I guess I'll just leave space for discussion now and any questions. That's an awesome overview that was a lot. One question came up I had the same Colton asked it as well. In the DIT peer, have you been following the DIT peer 3 and have you got support for DIT peer 3 in that? Yeah, we have implemented DIT peer 2 and DIT peer 3. Excellent. Okay, good. If we are synced up with like the latest developments, I know there was like some edits in the RFC. We might have to catch up on that, but we haven't yet actually integrated the DIT peer itself with kind of the state machines and the, you know, the areas kind of core component. And it's more of a plan to be part of the new state machine and the DIT exchange protocol we are just implementing now it should support the peer so we'll definitely, you know, be careful there. And make sure that it's like ready once it, once this kind of turns green or blue. Yeah. I had a question. Yeah, in regards to Unify. So these wrappers you mentioned with Kotlin and Swift. Yes, this will expose the areas to be CX API and engine. And what would you be able to do with those wrappers? Would you be able to, for example, create like a wallet implementation on the mobile side? Yeah, so you'll be able to do anything. I mean the end goal, it depends what we know how much this will be matured, what kind of, how much integration it will have with areas VCS, but technically you can propagate all the APIs we have in areas VCS, we can propagate, you know, we can enable in those Kotlin and Swift wrappers. So you could be, you'll be able to do anything in those what you are able to do in areas VCS like Rust trade. Right, well, thanks. By the way, I believe that, correct me if I'm wrong, if somebody more familiar, I believe that Unify also generates Python bindings, but I'm not 100% sure about it. We mainly do it for the Kotlin and Swift, that's kind of the main goal though. Hey, Patrick, could I jump in real quick? Yeah, for sure. So on the Unify, just a quick shameless plug, I've written some tutorials on how to use Unify and what that means in relation to FFI, I put the link in the chat if you guys would like to take a look. One of the things that I've also done so Unify natively supports Swift, Kotlin, Python, and Ruby. I think it also does some other integration with CC++ although that seems redundant. One of the tutorials, the latest one I wrote, I needed to use a Rust library in Java. So what I ended up doing was creating a Kotlin wrapper and then going through the process of how to create that and then importing that into Java. And so some other guys have done some work integrating with C sharp.net. That's not part of my tutorials, but that's also out there. So all of this is growing, but if you'd like to take a look at my tutorials, they're a real super simple way to get started in that. That sounds great. I think this can be a great help for our mentee working with the Unify. Thanks for that. Actually, Patrick, on that note, will this mentorship program be open again to the community? So I think that Hyperledger, sorry, Hyperledger is organizing this once a year. And it's been happening for the past three or four years, I believe. So just extrapolating based on that, I assume that there will be another one in a year or so, but until then, you know, this mentorship lasts until November. And then, yeah, I don't know what's the Hyperledger plan for these mentorships in 2024. Thank you. Understand that mentorship, or sorry. That, that uni F, uni FFI. Basically what you do is you define what the interface looks like, and then you can generate. And then it's just generated from a single source for all of the different things you want, like you just say, oh, I'm going to do Python as well. Is that correct? Or is there got to be customizations when you do Python and other customizations when you do Kotlin? Yeah, precisely, I believe there's no need for other customizations, but maybe Steve, Steve might know better. Yeah, that's true. You, when you create the language wrapper, once you've, you start with creating a UDL, which is kind of like Web IDL representation of the interface you want to create. And then it's a single, single command line command to create each individual language wrapper. So once you've created it for Python, let's say, when I create it for Kotlin, it is literally one, one command line command to do that. Okay, so it's more you're, you're maintaining this. I can't remember. You need this, this definition and then, and then just generating from there. Okay, good. Yes. Seems worth the effort. I've enjoyed it. So I'm a strong proponent. We, I looked at doing this without Unify a couple of years ago, taking the Ascarb library and porting it over and taking it to the FFI based Swift implementation that we created because it felt to Swift developers like C and Swift developers don't like that. And so this makes it feel like the native language. Mozilla has done some really good work on this one. And then the other comment I made in the chat Patrick is definitely as, as you're looking at that meteor project. And if you're looking at supporting Web sockets definitely look at the work and DC has done and contributed to Aries in the Aries socket dock repository. I heard about that. But thanks for additional heads up. I'll see how we can harness that and try to save ourselves some work with the Yeah, and the other thing is I think this is the most active. Well, I'm sure there's other stuff going on around socket dock but right now. Yeah, if you're doing mediator and you've got a project like this I think it would be worth taking a look at it. Thank you. Any other questions. This has been a great summary. That's that pictures. Awesome. Thank you. Excellent. All right. Anything else you want to share. No, I think, I think that's it. That's all I had. Thank you. I'm just going to start grabbing the sections, the intro and the sections out of the recording so you've got those as well. I think it'll be, I suspect it'll be a YouTube so it might be just links into the starting points but I'll let you know when they start. Thank you for those for other purposes. Great presentation really appreciate it. Thank you. Thanks for space to talk about. Okay. As we talk about more general areas things we definitely would love to have you folks if you can make this time time slot. Have you joined in because obviously there's lots of things we can learn and share and make decisions about together so that would be very helpful. Status of the Indie Indie SDK basically. I did a short presentation and I could probably bring it up again but on the Indie contributors call yesterday, but talking about the need to deprecate. The Indie, a lot of what we've been talking about today or a lot about what Patrick mentioned is the transformation that BCX is has done. But we really need to more aggressively in the community deprecate and perhaps archive the Indie SDK repository. I mean, in the Indie project we're talking about that. And I wanted to make sure the, the Aries community knew about that and was taking steps to do it because part of the work is, is for the Aries frameworks and libraries to take into account, you know, make it so that there's alternatives to you from using the Indie SDK. But then there's the those that are using the frameworks and using the libraries to do that transition as well. For anything new, nothing, you know, nothing new should be starting with live Indie as the basis. So if you're starting new with Aries projects should definitely be on the non not using live Indie. So those that are using it there are conversion and migration tools and we're going to be highlighting those in the next little while to make sure as much as possible people are moving away from the away from Lib Indie and and over to the newer tools the both more more stable and better maintained shared components or the tag that's used for all of them is just ask our based right now but it it encompasses both Indie BDR which is the interface to Indie. And then ask our which is the storage component, and then either credits, or an on credits hyper ledger and on credits as the non credits implementation. Those are the three components that make up the Indie SDK and, and those are the new components that we're transitioning to. We just need to push that transition along. We just need to get that to get that word out there. I don't know if anyone has any other follow up or comments on that. I believe if you're using VCX AFJ or acopi it's it's pretty easy to use the other tools instead of Lib Indie and, and as I say definitely start doing that because we need to deprecate the Indie SDK. That's all I had I guess we do have a little bit more time than I had expected. Sorry for for making you compress Alex, your session for given. All right, thank you. Any other topics people want to raise I see there's something in chat. I have a question from Daniel Daniel you want to jump on and ask. As just as a follow up to the unified discussion. Does it support generating like idiomatic async in the rappers that it generates. Pretty straightforward question just curious. I know that there was a last time I checked those some issues about you know using async. In the community and there was some PR PR addressing that so I believe if it's not already there, they're definitely working on it, but again maybe Steve know my no better here. Steve, do you know. I haven't used the async capabilities. Maybe that needs to be part of another tutorial. I do know they're working on completion handling and that's the codes been rolled into the database already for the next release so hopefully the future completion stuff is. Is imminent. Yeah they have some fixtures for async handling and Colin Swift. But I don't think they've officially released it yet because it's not in any of the docs just yet. But it seems like soon. Okay, interesting. I would read a tutorial about async interfaces generated by unified so I definitely be interested in that. Okay, I got one reader. I'll get right on it. Daniel's point is that's a pretty core part of what of what we're doing in areas and pretty crucial feature is that that's the motivation for the question. Yeah, yeah. Yeah, so when I when I looked at it. When I was working on one of the first things I was working on with Unify was areas as car. And there's, there's lots of the lots of those futures in there. And so what it caused me kind of an architectural introspection, if you will. Do the futures belong in the library or in how the library is called and I know we could debate that back and forth and there's probably no right answer. For for now what I've been doing is putting that kind of stuff in in how the libraries called versus in the library itself. So once that capability is, and the reason for that is how certain things are handled crossed language kind of matters. And so, Kotlin, or Swift or Java or whatever might have some nuances that are different than rust. You know, how do they when when you go cross language programming like that part of what you need to keep in mind is how the differences synchronize. And so that's what I've done so far. But with with these futures emerging from Unify. Maybe that'll smooth all that out and it won't be an issue but that's, that's where I've done things before the other thing that I've done is, well let me just leave it at that so I'm following that and as soon as that becomes GA from Unify, I plan to write a tutorial specifically on that. Excellent. Okay, any other questions comments. With that we wrap up. Sam is away for another week. So I'll be back again next week if anyone has topics they want to discuss. Let me know. Otherwise, I will plan on probably getting us back into issues related to transitioning the community transition of unqualified kids, and some other areas are FC things that are coming up so sort of issues that are across the areas community. I'll welcome other topics just shoot me a note on discord. And let me know. And with that, I will wrap up this meeting thanks all for joining. And thanks especially Patrick great presentation and the team with areas VCX looks fantastic work. Have a good one. Great presentation. Thanks all.