 sovereign mobile devices. Our speaker is Paul from Australia who is both the creator of the M65 retro computer and the Serval mesh networking, mesh network telephone system and this project is basically combining these two into one amazing device. Please give him a warm round of applause. Thanks. Today, well let's start with an apology. I had intended to give this talk actually using the 8-bit mobile phone that we're making. Unfortunately, the VGA connector is wonky so we're having to fall back to the old-fashioned solution here. But if you want to, there was a video that I made in New Zealand in January at LCA and we got the entire presentation there using a different one of these prototypes. So yeah, have a look at that if you want to see in action making phone calls and the whole kit or come and grab us and we can have a play with the one here and maybe even get this one working in a nice way for folks as well. I just thought I'd start with this picture of horror really. I'm an Australian, I live in Australia and someone thought it would be a good idea to put Vegemite into pretzels. Clearly this is a bad idea but it just struck me as embodying in many ways the whole problem of the issues we have around proprietary hardware and the loss of sovereignty of our digital devices. We should be able to buy a pretzel that doesn't have Vegemite in it if we want one that doesn't have Vegemite in it and it just gets to the heart of the whole issue. So what I really want to go through today, in many ways it's more on the philosophical side but using what we're doing is a practical example around that and it is really around this issue of digital sovereignty and how we can make mobile devices that are truly digitally sovereign in a way that no other mobile devices are and that are actually still useful to use. And in that there are all these questions around how we can make devices that are actually maintainable because it's the maintenance of capability that's actually harder in many ways than the creation of capability in this particular space. And then as we start thinking about different radio types and things that we can make devices that are independent of infrastructure, independent of energy, we need to think about how we can handle complex untrustable devices in a way that makes them still maintainable as a capability to use. And then finishing around how we can make new interesting mobile devices that have not really been possible to do and to do that with much fewer resources than it currently takes. And then having a look at the very end about how we can do that with radio. So my goal is we'll be finished with me talking in the next 25 minutes or so and have plenty of time for questions but we'll take it fairly flexibly. So what do we mean by digital sovereignty? And my thinking around this has really been around what do we think about as sovereignty for normal, in a normal kind of way of life. So this really is actually that people should be able to create, modify. So what the things we understand from the GPL ought to apply in practice to the devices, the software systems and things that we're using. And this means as we know innovating without permission, changing the purpose, making something useful in a new and different way. And also should be able to sustain capability. And this is the thing that I will keep coming back to. That we need to be able to not just make something but actually be able to make something that can be maintained in the long term for it to actually be practical and useful. And so I took a look at what the Wikipedia definition is for sovereignty. And this is a really interesting point that's hinging around the full right and power of something to do things itself. So if we think about the digital world, it's our full right and power to be able to have a digital artifact and do what we want to it without any interference, without any hindrance from any outside sources or bodies. And this actually makes this really interesting point that the right to modify, the GPL gives us the right to modify. So we can modify the Android open source software project or various other things that are under open source licenses, whether GPL or other ones. But it doesn't mean that we necessarily have the power to do that. That it may require so many person months of effort to even just get the thing to compile, let alone to actually understand how it works enough that we can use it for a different purpose. And so the practical effect of this is a digital sovereignty, and I think we're all probably fairly conscious of this, lags behind physical sovereignty in a fairly significant way. So if we compare just a conventional bucket that you would use to carry water or whatever and a smartphone, we actually find that our freedom, our sovereignty over these devices is wildly different. So with a bucket, we can use it until it breaks, right? We can carry water, it doesn't need updates, the vendor can't make that bucket retrospectively no longer useful. But with smartphones, we see these kind of issues. It's much easier to make a bucket by yourself than it is to make a smartphone by yourself. So the power to make a sovereign smartphone is greatly diminished for us. And of course, we can repurpose a bucket to do whatever we want, you know, whether that is using it as a helmet with eye holes or to carry cheese instead of water. Like it doesn't matter, we can use these things as we want. Whereas with mobile phones, we find ourselves to varying degrees trapped in sandboxes, particularly critical as we know on the iOS devices, but even on Android, you know, you need to root the phone to be able to do certain things. And there's a complexity in there that actually again diminishes our power to be able to do that. And then likewise to be able to innovate to make a better phone or a better bucket, this is worlds apart in terms of what we're actually able to do. So this hasn't always been the case that in the early days of computers, they were largely digitally sovereign. So if you bought a Commodore 64 in 1982, the documentation actually told you how to do a bunch of things. You could buy books that had a disassembly of the entire operating system. And, you know, Commodore didn't sue anyone for doing that because they knew that it would sell more units if people could do more things with the computer. Now, of course, things have changed quite a lot. That partly the growing digital economy and these concentrations of power that's created, that these large companies say, well, you know what, we can make more money if we actually control the way people use things. And that invariably means also restricting what they can do. And actually just the complexity of the devices makes it hard for us to actually be sovereign over them. Again, you know, in theory, you know, I've got a Fairphone 2, so it has an open source operating system version available for that. And I could hack on that. And indeed I can if I want to. But the effort required to do that is actually tremendous. The learning curve required is tremendous. For most people, that's a power they simply cannot in practice exercise. And so this is the problem. And then we have the related issue around planned obsolescence that, you know, companies want to sell new stuff so they don't care about maintaining old product. Why would you spend money doing that when you can be making a new product and making it so that's better and people want to buy it? And you might even go so far as to restrict even further the ways that people can use the old device and give various reasons around that. And there is, you know, this saying from Microsoft that for them, for many years, their greatest competitor was actually the previous version of their software. And so these behaviors can be active or passive, whether they're trying to do these things. And as I say on the slide, this is very naughty behavior, indeed, if we actually want to be able to let people own the things that they have paid for. But again, I think that actually is second fiddle too, this problem that it is the complexity of modern systems that really, really undermines their sovereignty or our power of sovereignty over them. That the more complex something is, the harder it is to even know where to start to be able to make any changes. And so there's this huge effort required, you know, for example, take Android again. If I wanted to maintain an improved version of Android for my fair phone, I would probably need about 10 of me working on it near full time to realistically keep up with that in any really effective way. And, you know, this is even worse if I wanted to actually control a baseband radio in the phone. You know, I can't even get documentation on that. And so, you know, if we want to make fully sovereign mobile devices, we need to change the way that we're doing things. And as I've been reflecting on things, and as was said earlier, that we're making this Mega 65 retro computer, and I'm also leading the server project, that it occurred to me that if we can actually get the simplicity of the 1980s home computer era to be the controlling piece of the phone, we can actually break apart the complexity and restore the sovereign power over the device as a whole. And we'll go on more in that and so then what actually makes it so hard to make a mobile phone? If we want to make fully sovereign ones, we need to understand what the challenges are. The first point really is actually making something that is that small and electronic. You have these tiny circuits and it's just it is simply hard and expensive work to do. And then, you know, how do you connect the devices together? There is a whole bunch of complexities around how that works. But it gets worse. The software is actually really hard to get working. If you make a device, you go, okay, right, I have a new improved phone that has something that I want on it physically, and now I want to, you know, support Android or some other operating system to it and maintain that. This is hard work. And, you know, I love what Fairphone are doing and I love what Purism are doing and I hope they keep on doing it and continue to grow in their capability. But I think both of them would, if we were to ask them, agree that it is a lot of work to maintain a port of Android, let alone to add new features in or indeed of a whole mobile operating system, whether it's Android or not. And then from an open perspective, again if we want full sovereignty, we actually want to be able to trust the hardware. We want to understand how it works. We need to have a mobile radio that we can actually trust and use in a sensible way to protect our privacy. And this basically is impossible to do. And then the cellular network is a piece behind that. We don't even control that. If we want to have fully sovereign mobile communications, we actually need to be able to replace each of those components. And this is no simple task. And as we basically said already, that even if you can achieve this, that maintaining it actually for a single person is basically impossible. So if we want individual sovereignty over our devices, we need to dramatically change the way that we design and make these things so that the barriers to entry are reduced that a determined individual can say, I want a phone that has some characteristic about it and actually create that. So before we go further, just a quick note. As we've already mentioned, from Purism to Librim 5, and there's a bunch of others as Wi-Fone and things there are, I am so glad to see that there are all of these other projects around open mobile devices with varying goals. And they're different things. I love the diversity that that brings, and there are fresh ideas coming from all of them. So I don't want in any way to discourage those projects or talk them down. On the contrary, we all need to be chipping away at the castle walls if we actually want to get to the point of freedom again with this. So I started thinking, how can we do this? And I thought, well, let's actually turn the whole planned obsolescence thing on its head. If you make something and you try and have it current all the time, indeed it's going to get obsolete very quickly, you have this maintenance problem. But what if we can actually start with something that is simple and by modern standards totally obsolete. In our case, it's an 8-bit computer platform, and work out what we need to trim down in order to actually make something that can work on that kind of simple system, and yet still remain as useful as possible. And because we're working on the Mega 65, that was a logical thing for us to do. But also, things like the Commodore 64 demo scene and game scene are actually still active. People are still working out how to push the limits of what should be a very constrained system that's not capable of doing a great deal. And in fact, it instead can actually do a lot. And so we have actually confidence that we can do interesting things with that. Indeed, at Linux Conf in January, we gave an entire presentation using a different prototype of the Mega 65 with its own slide software that we had a student write in a semester. So we think that this is possible to do. So here's a couple of slides on how we built a previous prototype just to give an idea of some of the thinking that we're trying to do around this. So your regular mobile phone is like the part of the top there. Everything is in one horrible insecurity domain. The cellular modem can often do horrible things to the CPU directly, whether the CPU even can notice them or not will depend on the architecture. And even if we sort of say, well, maybe that's not true for all chipsets, we can't prove it for any particular chipset without a huge amount of effort, that we simply cannot trust the devices because they are too complex for us to be able to determine what the architecture is in them, let alone to be able to do anything in that. So our approach instead is to break it apart and not just for the cellular modem, but we can have other things like a Raspberry Pi as a compute module that can run Android natively as a servant processor, a slave processor of what is effectively a Commodore 64. And we can make sure that that doesn't have direct access to the microphone, doesn't have direct access to the speaker, so that we can really quarantine that and do encrypted phone calls, all of these sorts of things if we want to in a way that we can actually be much more confident about the security of. And because it is so important for mobile phones, this whole thing of how we do the audio path and protect that from malicious devices is really important. So in the Mega 65 and the megaphone that we're building around that, we have this audio crossbar mixer so we can actually control every input and every output from the two and from the cellular modems to the speaker, the headphones, Bluetooth, everything, so that we can limit the clear text audio path to only where it needs to go. It also means that you can use Commodore 64 music as ringtones or play it as old music to someone on the phone if you want to because we have full sovereignty over the device. So this started then boiling down in our thinking to, you know, basically turning the whole idea of having a management engine on its head. If you think about modern complex CPUs, you have a reasonable degree of sovereignty over the main part of the CPU, the application processor. What you don't tend to have sovereignty over is the management engine in whatever form it takes on different architectures. So what if instead we actually say, well, we can't trust the complex processors, but we can trust the 8-bit machine, so we'll make that be like the management engine. So we're nominally calling this the little brother, and so that separates all of the components and lets us control what we want to do. Let's just do things like use a complete Raspberry Pi running Android because we can quarantine it. We could even actually virtualize its access to storage so that you could have multiple instances of Android and choose between them that can't contact one another. And of course the cellular modem, but we could have all sorts of other components. And because that connection between them is actually managed by an 8-bit computer you can program in basic, the barrier to entry to integrate that together is actually dramatically reduced. And of course it has the other side effects that we can boot it in under two seconds and you can play fun games while you wait for the cellular modem to actually boot up for you to be able to make a call. You know, again, you have full sovereignty to do what you want with the device. And by generalizing out the interfaces, so if we use the SODIMM form factor Raspberry Pi, it can be removable. And if a new version comes out, we can switch to the new version without us having to rebuild a huge effort for the capability. Likewise for the cellular modems, we can upgrade. So the current prototype that I have here currently has a single 4G modem. We have two bays, we could put two 4G modems in, or when a 5G modem comes out, we can put it in. And it's the industry standard mini PCIe form factor for cellular modems. And we've got the coupling quite loose. There is a digital audio interface, it goes into the crossbar and that's again industry standard. And then it's the UART interface with AT commands and you can do data over that as well at reasonable speeds. So that again, we have these things really separated so that they cannot interfere with one another. And for the cellular modem or the Raspberry Pi to have malicious software that tries to hack the Commodore 64 little brother piece of it is going to be really hard to do. And besides, it's very hard to try and hide malware in 64 kilobytes without someone noticing that there is a tiger under the rug, so to speak. And we can do other things with that, so we can have Genlock for the video so that we can do overlaying of the two together in nice ways, a whole pile of refinements that we can do around that. It also means that if you would be really paranoid at any point, you could actually take out all the untrustable components and be left with only the trustable core of the machine to do some sensitive actions. And like with the Librim 5, we have physical hardware switches to be able to turn things off. So again, we're talking about having a device which is, you know, that you can have sovereignty over. So I've been quite sovereign over the design of this. It has a bunch of features that probably half of them nobody else wants to see all together in a phone at the same time. So maybe they would like to have these two bays to put different radios and things in. We've put four microphones on there so that we can experiment with doing background noise rejection in a really nice kind of way, because I read a cool paper about it and thought that would be great. So, you know, $2 a piece, throw them in the design. We've put a full-sized SIM card and smart card reader in there, partly because I thought it would just be fun to be able to use a full-sized SIM card like on the really old Nokia phones, since we're talking about an 8-bit computer the size of a house brick. But also, we could actually make, if we wanted to, an electronic point-of-sales machine with the banking card reader in there, because it's the same physical interface. I like to play the old Commodore games, so I've put a 100 decibel capable 2-Watt speaker and amplifier in there so that it can do as loud as we want. We've got Bluetooth and Wi-Fi and a joystick plug, so we can actually use real joysticks again. You may not want this on your phone. That's fine. You can make it how you want and without a huge amount of effort. And because I do work with humanitarian sector, we want a device that we can use in the field for several days without being recharged. So let's put a huge battery in it and the entire back surface will actually be a solar panel with sort of between 5 and 10 watts of capacity. And because I lead the several project, I wanted to put mesh capable radios in there, so we've put tri-band laura in there that can work around it, and we'll talk a little bit more about that at the end. And so we could make totally different things. We could make a field hospital unit based on much the same hardware, but we can put the pulse oxy reader that goes in your finger and checks your heartbeat and blood oxygenation. We've already talked about having a point-of-sales machine or field data collection for disaster zones. There's a whole bunch of things that we can do. One more that's actually got me really excited is by effectively virtualizing an Android implementation's access to its peripherals, its physical interface peripherals, we can make a platform that makes it super easy to make smartphones that are customized for use by people living with disability of different kinds. So some people might be able to use a joystick because they only have gross motor control, but not a touchscreen. We could have that actually pretend to be the touchscreen to the Android without having to touch a single line of code or even recompile Android. So all 99% of the complexity has now been shoved out the way. Some code in Commodore 64 basic or assembly language is all that needs to be maintained to make the touchscreen interface, and so a person with disability could actually even iterate over that progressively to make it better for them without even having to come back to someone else for help. That has me excited about bridging the digital divide and doing great things with digital sovereignty. But the last five to ten minutes that we have, I want to talk about the challenges around having packet radio enabled phones so that we can make infrastructure independence with these digitally sovereign devices. So some other phones already in theory have this capability. You can plug a thing in the USB at the bottom, but that's annoying. The Fairphone 2 actually has pads in the back that you could make a thicket case that had an extra radio and things in there if you wanted to. But again, you have this whole problem of the complexity of the system, the effort to maintain the integration even if you managed to compile it and just not having the right size battery in these devices. So what we've done with the Lora radios for the moment, and we can do with any other radio that we want, is these connect via the little brother, the Commodore 64-like implementation, and they can even actually keep working when the FPGA is off to save power because we can independently control the power systems in there. They can do an interrupt that wakes the FPGA up to process packets if we have need to, and so it can be quite energy-efficient and do a whole pile of interesting things, whether it's at the protocol level or software-defined radio. There's a whole bunch of things that we can really do. And we just kind of hop through so that we've already covered the bulk of that. So I just want to talk now about some of the physicals and the legals around how we can try and do this kind of peer-to-peer telephony with a digitally sovereign device because, of course, on mobile phones we're really limited in what can be achieved, but with this actually the world is open to us to how we want to do it. So, first of all, there are a bunch of what are commonly called license-free bands, but they're not free of a license in the same way that GPL license code is not free of a license. What it has is a liberal license that lets you use it in really nice and reasonably sovereign ways with respect to other people trying to use it as well. Unfortunately, there's no single global band, and even in the regions that are meant to have harmonized regulation, this is not actually the case. And, of course, in Europe, you're actually particularly bad at the offers, I understand. You've got this teeny tiny bit at 868 megahertz and a little bit at 433 to 434, which I think has horrible duty cycle restrictions on it if you want to transmit it any sensible power. In Australia, where I live in the US and a few other countries, we're a bit luckier. We've got anywhere between 5 and 25 megahertz around 900 megahertz with one-watt EIRP or a four-watt EIRP in some jurisdictions, and that's much more useful. But, again, with a sovereign device, we can put all three bands in. It's not that expensive to do, and we can get creative about how we can use those in ways that are consistent with the social license around that and do really interesting. So we want to use GPS to work out which band to use and what particular rules apply, but not having to have it get permission from a central database because, at that point, you've lost your sovereignty. So we want to allow that, and we've talked a little bit about that. The 900 meg band in the countries that have it is actually really nice. You can get multiple kilometers even with a quite simple waveform, and with laura type radio you can get tens of kilobits over kilometers to tens of kilometers. So this is really interesting for trying to make a useful localized mesh network that could span quite a distance. So certainly we would have no trouble if we had it available here on camp from end to end with a bunch of people using it with carefully designed protocols, and that's another piece that's beyond what we have time to cover. And so also the 433 band, we've talked a little bit about that already. What's interesting is that this is now more available globally than it used to be. There seems to be a desire to allow import of European targeted 433, 434 megahertz band devices, so Australia actually recently allowed their use with particular restrictions that don't line up exactly with here in Europe. And it has a nice advantage that as we push down in that UHF band it gets a little bit bendier, it goes around obstacles a little bit better, and it tends to carry further with reduced loss. But my understanding, and you guys will know better than I do, that here in Europe it's still reasonably congested, and that those restrictions with the duty cycle are particularly limiting in practice. But again with a sovereign device, as the regulations change, or if someone licenses a band, we can actually make use of them. We're not limited to a defective vendor's implementation that is overly paranoid about the use of bands and duty cycle, or maybe they've just implemented the most horrible, narrow common set that works in all jurisdictions. An 868, similar kinds of problems to 434, because I think it's only a quarter of a megahertz wide that's practically usable and is quite congested once again. But we don't have to stick with those bands, depending on what you're trying to do, there can be a bunch of different options available. So there are some legacy bands like Citizen Band Radio, it depends on your jurisdiction, whether you're allowed to do digital over it, and if you are, what waveforms and duty cycles and things apply. But it often gives you quite a number of channels, and again down at the 27 megahertz kind of band for the old VHF CB, this is really quite nice and bendy and will go in many cases sort of around a hill or two, and can be great for hooking people up in remote areas. And even the UHF CB ranges can be quite decent and often these will have much higher transmit powers. So whilst your data rates may be lower, it may be more practical when you actually try to use it to get communications over long range. We're thinking the target kind of applications is text messaging and small file exchange, not full on live voice and things. Although again with work and a sovereign device, people can explore that space and try and push the boundaries. Or you can just go and license some spectrum. Depending on where you're trying to work, this can actually be quite cheap. So we do a lot of our field work in the outback in Australia where the spectrum has practically no value. No one wants to license anything other than the main cellular bands. And so for a couple of hundred dollars a year, we have in the past and can easily again license quite a nice slab of UHF frequency, possibly even down to VHF so that we can get really long range. But again with full sovereignty, we can do even crazier things if we want to. We could actually tie in HF radios in a hybrid kind of network. And this will be looking at with a several mesh as well, so that we can choose the right kind of link for the right circumstance and actually make a whole infrastructure that for communities will allow them to communicate even over long range. So with HF, we could hook up islands in South Pacific island nations, for example, who currently have to depend on satellite phones or literally getting in a boat and going to the next island. But also because we're making a fully sovereign device, we could do software defined radio if we want to and FPGAs are great for that. We have an FPGA implementing the little brother. So this could be done. And again with some care and distributing updated bit streams via all of these same kind of communications protocols, we can even update in the field in near real time the capabilities of the device because we have the sovereignty over. We don't have to wait for the vendor to decide whether they even want to help us solve a humanitarian need. We can just get out and do it. So as we start to get to the end, there's all these different barriers. The whole protocol area around this is still an open one. There's been a lot of great work on mesh communications and peer-to-peer and delay tolerant. What I would say is that with this kind of system, the best place to start is actually with delay tolerant communications and things like text messaging that has high value and really can facilitate useful interventions and capabilities for people, but without being so complicated to implement in a robust way that can work on these kinds of bandwidth constrained networks. But this isn't to say that people can't work on new protocols that continue to push the boundaries. And again, if we have the freedom to innovate the radio and be able to try these things in the field so that we can really rapidly innovate without permission, then I think we can actually do a whole lot more. And so for us, we're going to look to port the several rise and delay tolerant networking protocol to this device. We have the Lora radios and to see what we can do with that. So in conclusion then, I really just want us to reflect on this whole issue of the digital sovereignty that we have lost, but that I think we can actually reclaim, that with carefully designing these compartmentalized architectures and having the piece that binds it together, the one ring, so to speak, but instead of binding in darkness, that you can bind us together in the light to be able to do great things, so long as it's simple enough that everyone can learn how to use it and adapt it and make it better. And to demonstrate conclusively that we can remove these barriers, I mean we've made this device, I reckon it's cost us 500 euros give or take from scratch in hardware and it's been myself and two or three students over a span of less than two years to make a device that we can carry around and that's capable of making encrypted phone calls if we so wish. So we're confident that this can be done and we would love for others who would like to even just replicate what we've done or have different ideas about how it should be done. Again, we want to emphasize the sovereignty angle and to work with us to really bring this to be a reality and to help people who can benefit from it and just break up this whole problem of lost digital sovereignty. So at that point I will stop and I'll be delighted to take any questions that people have. Okay, we have about 10-ish minutes for questions, so there should be some microphone angels jumping around, I can't see anything from the stage, but make yourself visible to them and beautiful things will happen. While we wait for this, could you maybe just hold up the megaphone? Yeah, sure. Because I feel like I couldn't really see the size. Yeah, I mean this is what we've just built in the lab, so it's laser cut for the different layers for the case, because that was easy, but you know, it's a nice adult size, game console size, and we can easily reduce that size down. Again, it just takes effort to work on the different pieces. Now I thought I saw a hand back there. Yes, could we go there please? Okay, we have someone ready with a question. I saw someone. Okay, yeah, this thing's on. You've talked a lot about the capabilities and all of that, but not really much about distribution or fabrication. Is this something that you can get a kit for, or do you need to like make the PCB yourself by all the parts, etc., etc.? Okay, so at the moment we don't have kits. We're not at the point of having a refined PCB that you would even want to build yourself. We hopefully will be at that point in a few months. And again, these are all areas that we would love to have the community work with us to make it reproducible in the first instance. There will be some effort and learning curve initially, but then we want that to vary rapidly. We know that it can rapidly tail off so that people can buy a kit or even buy a complete unit. What's interesting with that is with the Mega65, the desktop retro computer, is that we actually have a path to market outlined around that. And so we could actually leverage that to simply sell this as a game console to make enough scale of economy to start doing more interesting things with it as a platform without people even having to build a kit themselves. So do you have a website or a GitHub? We absolutely do. If you go to the Mega65 website, mega65.org, there's a feedback form and you can just basically, that'll contact me directly. Or hop over to GitHub slash mega65 and there are some repos there. Okay, thank you. Do we have a question from the internet? Is there a signal angel in the room? There are no questions from the internet. Okay, internet, ask some questions, please. And now, please, another from here. Hello. First, thank you for making this great idea possible. I have a question. I have seen that you are planning to do encrypted phone calls and using some public frequencies in WeJF, VHF or PMR and possible. Unfortunately, the law in Europe in all the countries as far as I know in the US restricts the use of public non-commercial frequencies with the condition that no form of encryption or voice crumbling even is possible for analog and digital. Yeah, so this varies by jurisdiction. But there has to be gap in that because on Wi-Fi, which is one of these publicly licensed frequencies for 2.4 gigahertz, we're all totally allowed to do HTTPS, which is encrypted. So yes, we need to look at the laws and find out what is possible and what is not. One of the other things that we found that's really interesting is that in most countries, one-time pad is not restricted because effectively it's one bit encryption, one bit per bit, but the keys are only one bit each. And so if it's known people you want to communicate with, it's quite easy for us to have a secure physical one-time pad on this device that these untrustable components can never get access to, but the little brother can mediate access to. So there's a whole bunch of interesting new ways that we can do this that can really give secure communications and in a way that's consistent with national law. I fully agree, but I just wanted to point out that in some countries like Slovak Republic, Czech Republic and so on, the wording specifies any form of it's just a simple sentence. So I will be really happy if this will be possible. Yeah, and it would be interesting if the law is that straightforward, it may be worth someone challenging on the basis that clearly HTTPS is a form of encryption and you don't mean to exclude that. Thank you. Okay, what about the internet? Still no signal? No questions. Then please continue. Yeah, well this is an amazing project actually. I'm glad somebody took on on this idea. My question is, as far as I understood, you could be able, instead of using an 8-bit platform which can be trusted, you could put your knowledge into an FPGA IP core and gain more processing power or put in whatever you want. This is an excellent point and we've already done it. The 8-bit processor is all in an FPGA. We've implemented the Commodore 64 and actually the Commodore 65 prototype system that was never commercially released and it actually extended that a little bit. We can run at 40 megahertz instead of one. We have a little bit more RAM than the Commodore 64 had and DMA and a bunch of other useful things but it's something which is still architecturally simple enough to understand, but you're absolutely right. And so all of these, this thinking is fantastic and the more that want to pitch in and work with it, we'd love for that to happen. You were great. Just one question. You did a lot of field tests, as far as I understand. What's your working background, you and your colleagues? Okay, so I work at Flinders University and I teach computer science, networking and security and so the field work really is around the several mesh which is around disaster communications. We work with Red Cross, World Food Program and a bunch of organizations. I'm happy to talk to folks about that anytime on campus as well. Cool, thanks. All right, next question from the room I guess, if the internet is silent. I was wondering what was the freedom status. For instance, what FPGA toolchain you use or will all the software be free software on it? Yeah, okay, so this is an area that we would love to have some help with. The FPGA we're using is a Xilinx FPGA and we're using at the moment the proprietary toolchain. I don't like being stuck in that situation. So we would love for folks to be able to nibble away on that part of the problem and find solutions and even open silicon would be fantastic to do if we can get to that point. I would love to reach that point but at the moment we're busy solving all of the other problems around that to actually make a working phone that people can build their own of and compile within an hour and do whatever they want with it. Maybe with an ECP5 you wouldn't have the toolchain issue for the FPGA. Yeah, look and so again we would love to use some of the open toolchain FPGAs. We need help to do the porting because we're flat out doing all of the other bits and pieces so we'd love your help if you want to. All right, do we have another question? Well, okay now we can also do questions in German for interesting reasons. Is anyone else has a question? Does the internet have a question? Okay, I do actually have a question. So in the end you were talking a lot about bendiness of the signal. Can you say something more about the physics behind that? Yeah, okay so basically the longer the wavelength of a radio signal the bendier it is and conversely the shorter the wavelength the less bendy it is. When I say bendy this is of course a highly scientific term for getting around obstacles. Okay, but how does it bend? Deep physics, electric would be possibly a better person to answer that in detail. But if you think about waves in a puddle of water if you make big slow waves they will bend and refract around obstacles in all manner of crazy ways and you get the back-slopping of waves. If you make little ripples that have a short wavelength let's you see they don't bend anywhere near as much it is literally the same thing happening just with atoms instead of water sloshing around. All right, very cool. Do we have another question? It can also be even more physics-based for the physicists in the audience? No? Okay then please give us a warm round of applause. Thank you and of course if anyone wants to catch up and have a look at the the phone or the desktop mega 65 prototype that we've got here or just otherwise catch up. Yeah come grab me. We don't really have a fixed spot where we're hanging out but you know my mobile number was there at the the beginning if we just hop back momentarily. In the meantime two toilet-related announcements wash your hands don't steal brushes. Thank you. Yeah okay thanks.