And welcome back to tomorrow. My name is Benjamin Higginbotham. Before we get into our interview, I did want to give a shout out to all of the patrons of tomorrow who have up to make this specific segment of this episode happen. These are people who have contributed $10 or more. They get access to our Slack channel. We've also got tomorrow producers. These are people who have contributed $5 or more, and they're going to get access to international free shipping on our swag store to find out how you can help crowdfund the show as a tomorrow and get all those different levels of rewards. Head on over to patreon.com. All right, now we are joined once again by John Powell of JP Aerospace. Thank you very much, John, for taking time out of your Saturday to join us. I know it's been a bit of a long day. Oh, no problem. So let's start off with who is JP Aerospace? What are you guys doing? Well, we're a small aerospace company. We consider ourselves a private space program. We just had our 38th anniversary this year as an organization, since we incorporated it in California.  We had 180 PongSat student experiments and six of the MiniCube student experiments. And we did that run up to 95,000 feet on a high altitude balloon and it had a nice flight. And then two weeks before that, we just flew our new airship, the Ascender 36. And so we've been doing a lot of flying and a lot of building and a lot of work in the shop. On our, we have a hypersonic wind tunnel and we've been trying to get it to Mach 4 for a year and a half now or Mach 3.8. You can't quite break that. But there's a lot going on. So one of the things that you're doing a little bit differently, and actually we brought this up on a few shows a while ago is you're actually, you're doing balloons for the most part. So you're not doing giant vertical, vertical landing rockets or anything else like that. Your first stage is a balloon. Oh yeah, our first, our second, our third stage is a balloon. We are the completely crazy airship to orbit guys. And we've been working on this project for literally decades now. We're the slowest space program in history. Working out each technical problem, each technical problem as we go to see if we can pull this off. And what is airship to space? How does this, what is the plan? Well, the simple idea or the simple way to put it is we take a lighter than air vehicle to 160,000 feet, like balloons are flying to right now. And then we slowly start to accelerate it. So we take the good at 60,000 feet and then with a plasma propulsion system slowly start to accelerate. And instead of over six minutes accelerating to orbit, we take up to 10 days to accelerate to orbit. But we start our acceleration and our orbital insertion at 400,000 feet way above the atmosphere. Essentially we wanna change the whole nature of space travel by taking the rocket completely out of it. But as was brought up in the chat room, I believe this is brought by Vogan. You can't fly a balloon to space. You know, those gases are going to expand. So how do you deal with it? There's a certain threshold that you just can't go over. How do you deal with that? Well, actually it's dynamic climb to orbit. Think of it as a flying giant flying wing. We actually are getting no buoyancy or it's diminished buoyancy and we're neutral at around 230,000 feet. And then that's when we actually begin to accelerate the vehicle slowly climb. We don't even break Mach 1 to over 300,000 feet. Where they were taking balloons in the 60s, the project shop put balloons, they were flying them at Mach 10 at three to 400,000 feet. It's kind of our first goal is to replicate that old 60s technology and get our balloons going at Mach 10 or not quite, but almost halfway orbital velocity at three to 400,000 feet. So the question becomes, well, they could do that in the early 60s. Can we push it a little faster today? If with 40, 50 years more advanced technology, can we go to Mach 14 instead of Mach 10? Can we go to Mach 15? How far can you take that technology? And that's the question that we're trying to ask at JP Aerospace. I can't tell you if we can actually go Mach 22. But I can tell you it's important enough question that somebody needs to find out. And that's what we're doing. How fast have you gotten the system to go? With the smaller vehicles, we've been up to Mach 3.5, but that's nothing as part of our bigger system at all. And that's not been driven with our primary engines. That's been driven with solids. Right now, our biggest airship we built was a little bigger than a 747. And we actually, that was a custom build we did for the Air Force about 12 years ago when we built a whole series of these big B-shaped airships for them. Our latest series, we built a 26-foot airship that we flew last year a couple of times. And then we're building a 36, we finished the 36-foot, the Ascender 36. And we flew that about two months ago now. And that one looks like this. Got props? You have to have props. And that was the, those were the blue balloons that we showed earlier, right? The giant blue, I think Dada's got him coming up here. Here's one on the ground, right? You flew, I saw pictures of this flying. This is what you flew just a, you said a couple of weeks ago? Yeah, well, that one's about a couple of months ago. We just flew literally last weekend, but one of our conventional balloons that we fly our payloads on. And this one, even though it's smaller than the ones we built in the past, it's with all the new technology in it. The internal structure, the internal balloon lifting cells, the command and control system is completely different on these new smaller vehicles. And it's cheaper to test these on small vehicles than the really big vehicle. So one of the questions from the chat room or more of a comment says, this is from Space Cookie 84. Says, that's cool. So basically you're waiting until most of the atmosphere is below you before you're putting the pedal to the metal. And you're not really putting the pedal to the metal. You're more kind of just very slowly continuing. You're just never letting go, right? You've got a very slow moving vehicle, but you never let off the accelerator. Exactly. So based on that, the 50s, assuming the late 50s, early 60s were just mylar balls. And they got these very thin mylar balls to go to Mach 10. And they didn't quite get all the way around the earth. They didn't orbit, because they're only 400,000 feet away in Mach 10, but they were getting literally circling the earth and not just ballistically. So again, ours are a little sturdier and have their own propulsion rather than just be pushed by solids. So one of the things Space Kyle mentions, Mach speed is relative to atmospheric pressure, more specifically, it's the speed of sound which changes through atmospheric pressure and density. So you're saying like Mach 10, is that Mach 10 at sea level or at that altitude? At sea level, Mach 10. Okay. As just a number to explain. Sure. As the Mach number changes up there. So using just kind of an absolute, will you be able to hit, are you targeting like the 17,500 mile per hour range? That's kind of generally considered orbital velocity. That's the number you're trying to reach. But the question at this point is, can you reach that number with balloons? You know you can push them forward. It's just, can you make 17,500 miles an hour? Yes, that's the question. And one of the big parts of it that we're doing in the lab is we're doing active drag reduction. Again, this is a lot of stuff that was in the lab in the 60s and 70s. And you can search and there's literally hundreds of IAAA papers on it on electrically reducing drag by emitting plasma in front of the field, breaking up the shockwave at hypersonic speeds. And right now, we really need to be getting to Mach four for that testing to really be valid. And we're doing a lot of our wind tunnel testing in the shop here. And then we just got our wind tunnel, say we're at Mach 3.8, starting to do that kind of research. Because even at 300,000 feet and 400,000 feet, you know, you get up close to where Alan Shepard went, there's still a lot of drag up there. And so we need to reduce the drag by about 40% to kind of close the loop to make that work. And the 60s, they were getting 80 and 90% drag reductions on those systems. But those were in the lab. And we want to take those lab experiments and put it in the real world. And that's a whole different can of worms. So what does it take to take those lab experiments and move them into the real world? Is it a funding issue, a time issue, a building issue? What do you need to get from A to B? Well, next fall is mission. We fly about five missions every year. And we're all independently funded. We're crowdfunded. We do small contracts. We do a lot of TV commercials. We did Margarita in space for National Margarita Day for Jose Cuevo. We did the chair in space. Oh, I remember that. The chair in space, absolutely. Yeah. And that's actually a full-sized chair. That's really cool. Above the chair is the big balloon platform, these carbon booms coming down with IMAX cameras all around, you know, filming all that. And even though we're just, Nicollin Dymd is barely making it, we've never missed a mission or build a vehicle, never had a problem due to lack of funding. So you mentioned crowdfunding is one of the things. Is that an active campaign like on Kickstarter, Patreon, something like that? Or is it just kind of- Oh, we have something going on now. We've done two successful kick starters and we're ramping up for our third. We'll probably be starting that in about four months because it takes a lot to put one of those together. And that's mainly to fund these, our Ponsats. And we're actually the largest student payload program in the world. We've flown more student payloads by an order of magnitude than all the rest of the world's space programs combined. We've now flown with this last mission last weekend, just over 18,000 student experiments. Oh, wow. It's about 75,000 to 80,000 students have participated. And on this last vehicle, there's like the one in the picture there. There was about 480 student experiments. And some are real simple. You're like little marshmallows that puff up in vacuum or plant seeds. And some of them had GPS's and cameras. We had one that had a GPS, a camera, and he was taking pictures every 10 seconds and then altitude stamping each of the pictures as he went. And then it also had cubes. You know, like CubeSats? We have a smaller version called the MiniCube. And this is one from Eastern Florida State University. And it flew on the last mission. This is a double stat cube, because there's a cube here and a cube there. And he's got a whole range of sensors in doing their experiments. And we fly a lot of these. The Ponsats were always free. In fact, most of the money doesn't go into the Airship Door Program. Most of the money from the TV commercial pay for flying ping pong balls. But the universities pay for flying the cubes. And that also helps pay for the CubeSats. And then on each of these missions, even though they have all these education payloads on, there's five or six Airship Orbit experiments. So anything that goes on an airship before it flies on the airship will have flown to the edge of space a dozen times on one of the balloon vehicles, just testing it and doing shake down.  But literally every couple of months, we're doing the flights, flying the missions, crossing one more impossible thing off the list. So it sounds like you're using the balloon missions and the Ponsats and the very small CubeSat missions as a way to test out the technology for your airship to orbit stuff. Then once you get airship to orbit kind of working and moving faster and actually making it into orbital speeds, what's kind of the game plan there? Is that a, is something that helps reduce the cost of objects to orbit? I mean, what does the advantage of airship to orbit get me? Oh, we wanna change the whole nature of space travel. Right now, it's like to use the shuttle as an example. Except for right near the end, if you have an engine out, it's called, they call it LOC or loss of crew event. There are so many things that are loss of crew event. With the airship to orbit, say you're right in the middle of the final orbital insertion burn and your engine conks out or anywhere on there. Well, you go have a meeting about it. It's not like you have to make everything right and save the crew in the next four seconds for everybody's dead. You have a meeting about it, you talk to the people on the ground, you have a big conference call. We had a couple hours, you go work in the back, tear down the engine, see if you can fix it. And if you can't fix it, you float back down. And the idea is that what if you took off in your 747 and everyone in the control tower, every time it tooks off, everyone jumped up and cheered, oh, thank God, everybody made it. You wouldn't wanna fly on 747s. But that's what happens every time we fly astronauts to space. The moment the rocket shuts down, everybody jumps up and cheers and cries because they didn't kill everybody. We wanna change that. And also, it's a completely reusable system. Right now, a transatlantic travel is five cents per ton mile by container ships and a modern container ship is an amazingly sophisticated vehicle. Not quite as sophisticated as a space shuttle but pretty complex in its own right. We wanna bring not the thousand dollar a pound, the mythical thousand dollar a pound from the 10,000 dollar a pound. We wanna bring it down to dollars per ton mile just like cargo is. How large do you need to make the airship to make that vision a reality? Oh, these are huge vehicles. You remember, they're also inflatable vehicles. So size, you know, it's like we built one vehicle that was a little bigger than a 747 but only weighed 630 pounds and that's the total vehicle I'm gonna enjoy. We're talking about a vehicle, our primary test vehicle that we're eventually gonna build is 6,000 feet long. It's literally over a mile long airship. So it's a giant airship. You can put humans on it, you can put cargo on it. Once you figure out the velocity part of it, right? So you're still testing, you're not quite there yet but working towards it. You mentioned one of the factors is safety and certainly chemical engines are, and even solids are scary, right? I mean, it's a controlled explosion which you don't really have but you are on a giant balloon and that balloon can, and this is a bit of a harsh term but it could pop. I mean, you could lose the structure of the balloon, could you not? Would that not be an immediate catastrophic? No, it's like our current airships. It looks like it's one big vehicle. If you did a cutaway, it's actually a series of smaller balloons all up and down those arms. And we can lose up to three balloons in flight and not even abort the mission. We lose the fourth balloon in flight and then we do have to not catastrophically fall but abort the mission and fall and fly down and land. So you have a point where even if you start losing structure, you can go, okay, well, we've lost too much structure. We abort at this point and you just, you come back and that's that. Assuming you don't continue to lose structure on your way back down. Oh yeah, well, if the whole thing breaks up but it falls apart and explodes, then everybody gets out. But so many things would have to happen for that. Like on the big one that we built for the Air Force, the 175 foot. On the top was six 14 inch diameter vents preventing helium. At 100,000 feet, those vents have to be open for about 45 minutes, all six of them before you can detect descent. Oh wow.  Well, the real trick isn't that you're calling falling to your doom. The real trick is detecting that that event has happened because the pressures are near vacuum. The flow rate across there is so low. If you have the meteor storm, you have six of them.  And what you do at the time you detect that you pump the remaining helium from those cells into the adjacent cells and you definitely abort the mission if you have a whole bunch of holes from meteors and mutants. It's an interesting concept, right? Because you don't have the chemical engine reaction so you're not worried about that. It sounds like you have some redundancy in structure. I mean, nothing's foolproof but you've got a good chunk of redundancy in structure. So then it's just a matter of, and how are you re-entering, right? Because one of the problems is you're going 17,500 miles an hour.  Do you just... We do our deceleration up high instead of down low. Re-entry temperature is really based on wing loading or surface area to mass.  The 6,000 foot vehicle, the max re-entry temperature is right around 71 degrees. So, in fact, the drag, even on orbit, the drag is so high you have to keep the engines on. You're truly not in a free orbit.  So let's go back to some questions from the chat room. One of them comes from St. Alex which asks about those engines, are they going to be solar powered plasma or basically what's your fuel for that? They're actually hybrid engines. They're not in the, well, only partially in the sense of the chemical engine, liquid oxygen and a solid fuel. They're hybrid in the sense of half plasma engine, half chemical engine. In a sense you have, in a chemical engine, the combustion chamber is where the fire is, where the plasma is. We're actually using that plasma from a chemical reaction to accelerate and then accelerating that magnetically like a traditional plasma engine. So it's half chemical engine, half plasma engine. People haven't looked at this kind of engine before because you could think of it as the world's worst ion engine, you know, traditional ion engine, they have a thing called ISP which is kind of a function of performance.  So they're basically for orbital things. And then you have your chemical engines that have ISPs in the 350 range or the shuttle, which was the best ever in the 400 range. But they burn all their fuel in moments and you can't really throttle them down.  You can't really run a shuttle engine you just barely on slow. So what this engine is, it's a small chemical engine. And then the chemical engine creates the ions or the plasma. And an ion engine, that's actually quite a bit of the power, electrical power requirement is in that creation of the ions. We actually do away with that power requirement by using the chemical engine to do that. And then on the backside, it's what's referred to as either a mixed ion gas or non-mixed equilibrium ion gas or dirty ion engine, then as a plasma engine to accelerate that plasma. The reason it's a terrible engine, it's either the world's worst chemical engine cause it can't even lift itself off the ground. Or it's the world's worst ion engine because instead of 60,000 ISP, it only has 1,000 ISP. You'd only need this if say you had a steam ship going across the Atlantic Indian engine that would chuck along for nine days and give you the reasonable amount of thrust. Well, that's what we have. We have the airship lifting that until we get really high and start dynamically climbing. So it's an engine that has no use on the planet except for our purposes. And we actually have a pretty vigorous engine program. And we've done about 119 firing so far, just all very small scale. And we've done four flights. We're actually, our test stand for our engines are at 100,000 feet cause we do fire them off at on platforms from our high racks. We have Ponsets below, rocket engines firing off the top. And that's actually coming along really well and we're starting to scale up our engines and we've now cannot fire the engines in our parking lot anymore cause the last one set off some car alarms a few blocks away, made lots of noise. We just recently now have our own facility up in Northern Nevada. The last couple of launches we did was from called the Area 42. So this 42 acres or the JPR Space Advanced Research Facility which is the fancy way of saying big plot of land with a cargo container on it. And that's where the next round probably in January of the engine firing test will be taking place.  You know, what one of the disadvantages of a traditional rocket is it's the chemical reaction is a controlled explosion. It's a very large, very powerful controlled explosion. And if you lose even a little bit of that control it's a very bad day. But if you're using chemical rockets on your vehicle how is that any different? Oh one thing, it's a lot smaller and we're burning at a much lower rate than you would. It's more akin to a jet engine firing than it is to a rocket engine firing. But that risk is there, it doesn't completely vanish. And then, so you're using these engines the other disadvantage of a chemical engine is you're going to expend your fuel at some point. You're 10 days to orbit. So are you bringing like huge vats of fuel or do you only need a little bit? Like how does your fuel work for a 10 plus day? The fuel, actually the chemical part of the engine is also a hybrid where the fuel is a solid and the oxidizers are liquid. So it's really cartridge based. And these engines are long. The engine is about 300 feet long. It's more akin to a linear accelerator that you keep a flame going inside than a rocket engine. And then it's also cartridge based. And so right now you have to literally open up the engine and replace all the cartridges between flights. You mentioned your oxidizer. What are you using for your oxidizer? Is it liquid oxygen, something else? Well for what we're doing right now we're doing nitrous and acrylic and we're moving to nitrous in the spring and a paraffin, you know enhanced paraffin, you know paraffin with magnesium particles in it. We don't see that being combination as being the final one. There's a lot of candidates for it. But let's say we're still, you know, right hip deep in the development process. I'm thinking it's probably going to be a LOX paraffin and magnesium combination. But that's, we won't really know for a couple more years. This question comes from Green Jim 2, which is, you know, we talked about this 10 days to orbit. Traditional rockets have launch windows measured in seconds or minutes because they're trying to, you know, make this particular orbit and you have to pass by it at a certain time. What does a 10 day orbit launch have as a launch window? Is it the same kind of you need to get moving? Huge adjustable launch window because you can accelerate, decelerate. We want to be in kind of the middle window. So if we need to drop down to 12 day insertion, we can make that change in flight or accelerate up to an eight day exertion, excuse me, insertion, if we need to. So we don't have those real tight narrow windows like a traditional rocket would. And how far does this scale? We're about to see the goes our launch in, you know, an hour from now or so. Would you be able to take that satellite eventually up to its intended orbit? There's the eventual vehicle. Our eventual dream vehicle is the 6,000 foot vehicle. Now our initial vehicle demonstrator for actually reaching orbit is only 1,800 feet, you know, baby 1,800 foot long vehicle. And that would only carry a couple hundred pounds to orbit. Our eventual goal is the 6,000 foot vehicle that will kind of scaling everything around is 60,000 pounds to orbit to Leo. Destructure 1701, space station's intact to orbit. Destructure 1701 asks, at the end of the day for your 6,000 foot vehicle fully laden, how long would it take to get, for example, to the international space station type orbit? Because assuming you could go theoretically, assuming you don't have power, you could go anywhere you want. Well, ideally, this vehicle will just take payload to Leo, to minimum Leo orbits. And OTV, you know, orbital transfer vehicle is really the ideal vehicle for taking it up to the station. You wouldn't want to drag this big airship and all that infrastructure up from Leo to a station altitude. So we're not really shooting for that, we're just kind of giant bulk cargo to Leo. But you could take bulk cargo that then from Leo launches itself up to the international space station. That's exactly it. That's exactly it. So would someone else develop those vehicles? You're basically saying, hey, look, we've got this big, huge thing, and then you go to, say, Sierra Nevada, for example, and say, hey, we'll get you really high up and going at really good velocity if you can make it the rest of the way there. Oh, exactly. We'd love to develop that top half vehicle, but doing that on top of doing all of this, I think it'd be a bit too much. It's almost like, what if we don't pull this off? Worst, say we only get back to what they did in 1962 and we got to Mach 10 at 400,000 feet. That makes an awesome air launch vehicle to fire a rocket on top of. What if we do a little better and we get to Mach 15 at 500,000 feet? Suddenly a Falcon 1 fired from there is like a Falcon Heavy. And that's if we don't make it, that's our... The other thing we can look at is once you're at those speeds and those payloads, you could use it simply as a refueling architecture for traditional rockets. So we want to go to Mars, for example. We need to bring fuel depots up to space. What is a cheap, easy way to just bring giant fuel tanks up there where we can refuel? This might be an interesting way to do that. It gets you a good chunk of the way there and then maybe a couple solids on the sides brings up the rest of the way to where it needs to be. Yeah, because air launch is getting more and more popular whereas kind of it comes and goes with Virgin Galactic and I don't know why I don't remember their name right now with the giant double 747. Straddle launch. Straddle launch, yes. And they're talking about flying from about Mach 0.8 from 50,000 feet for their air launch. They're great people, but that's wimpy air launch. Air launch should be 500,000 feet at Mach 17. That's air launch. Destructure 1701 also asks, what sort of materials challenges do the 1,806,000 square foot vehicles present in terms of stresses? The conventional stresses that you look in spacecraft design are well handled with those materials. There's actually some exotic stresses that are the real challenges. Because this is a flexible membrane surface, you get this phenomenon called hypersonic flutter. And usually in hyper like X-15 and hypersonic craft, you have flutter issues on the rudder and on the horizontal stabilizers. We actually have the problem of hypersonic flutter on the cross the surface of the vehicle. And that's one of the really extreme design challenges that we're trying to model in our hypersonic wind tunnel to start to get a handle on. Because if you don't have a handle on it, there's no known material. You can make it thing out of concrete in case in steel, in case in titanium. But if you have hypersonic flutter, it's not enough. So it's really, you can't handle it, you can't solve it through a materials solution. Unfortunately, you have to solve it through a management of the load issues. I mean, the solution has to lie there. All right, just a couple more questions. This one comes from Citizen 12708, which is why don't you put these firings on YouTube? The rocket engine firings I think he was referring to. I have about 20 of them up there. We do. They want more. They want more. They're all lying. Everyone wants everything. I'm still, I haven't got the videos from the last airship up there yet. I have to get these. When we ever we do the Ponsaps, all the kids get a documentary of their mission so they can see their ping pong balls. And so we're in deep, deep of making that. But I think I have like a dozen firings on YouTube. Again, these are all very small. They're not very big. These are little engines. And we've just scaled them up to be too scary to be standing next to when they fire, which is why we have to move out to the desert to do them. So those videos will be more fun because more fire, more flame. Hopefully controlled. Hopefully controlled. Hopefully controlled. Jimber asks, speaking of those launches, what's the cost per small sat launch? For what we're doing now? Let's say Citizen wants to bring up a Pong sat or yeah, well the small cube sats or something like that. Cube sats are completely free. We don't charge anything and we do thousands every year. These guys, this is our double cube. There is two, you can buy them in pairs and then when you buy them in pairs are a little cheaper but they're $340. And you get the cube and the flight for the $340. Now we also just, in fact, we announced it today. We've never had this before. Our new cube is called the Arduino cube. And it's elongated so you can put an Arduino board in there. And the Arduino boards or Arduino cubes are going to be $440. And that includes the cube and the flight of the cube. And we just flew our Arduino cube on this last mission. Last question before we go into the, we've got a little rapid fire thing we're going to do. And this comes from space and this is, during the last interview, which I think was about six years ago or so, you mentioned a high altitude propeller design. Are you still working with propellers at all? We did that. We pulled it off. We made the world's only tested high altitude propeller. Then afterwards the Helios people did that. Ours performs a little bit better but they spent over a billion on it and we spent about 6,000 on it. And that's part of what we did for the Air Force. And those drive all our, we've set the world altitude record for airships only two years ago. Oh, three or four years ago, time flies with our tandem airship. And those are six meter, excuse me, six foot blades. And we flew it to 95,000 feet, flew it around. And those propellers are, we're on that vehicle and they're on our airships that we're flying now. I'm just going to mirror something that Destructor 1701 said, which is, you're awesome. I love how far outside of the box you're thinking. And it's really cool to see new innovative ways. The fact that you're, I would say, normally we say bending metal, but you're not really bending metal. You're more like stitching balloots. I don't know what phrase to use there, but hate to think a lot of things together. There you go. You're making hardware. You're actually flying things. And you know, a lot of the traditional aerospace people might go, well, that's not space. Well, it's not space yet. Right? So once you get those velocities up, yeah. Yeah. The really thing is it used to be space when the X-15 program was going on is huge Titanic arguments that would get really heated between scientists where their space began at 70,000 feet or 100,000 feet. By the time the end of the X-15 program, the 100,000 foot guys won, absolutely. And they finally got support of the pilots when they started flying above them. But then it got declared when they got in that fight with NASA and the Air Force that it began at 50 miles. So the X-15 guys didn't count. That's more of a political thing than a science thing, but officially it's near space. It doesn't matter. You're working on stuff. You're working on stuff to go faster and faster and you continue to iterate on the design. And it's very cool. They're actually building things and making stuff happen. And I'm excited to see what comes of that. We were all excited with the balloon castles, I think is what it was referred to. And we thought it was just really cool. All right. These are a few questions that we ask all of our guests now and you can have really short answers. This is just, there are no right or wrong answers. All right. The first question is Moon or Mars first? Venus. Oh, good answer. Liquid or solid propellant? Hybrid chemical electric propellant.  What should the name of the first vehicle go into Mars be? Anything but calling it Mars or one of the variations are like Aries or? Sure. Just something besides calling the Mars mission Mars. When do you think humans will first land on Mars? Oh, I wouldn't say we're a solid 20 out. 20 years. I think we're going back to the Moon first. Interesting. That would be my bet. If I had to put a dollar down, I would love it to happen sooner. But I think we're 20 years out. I think we're gonna get close and then we're gonna zoom over to the Moon. That ties to my next question quite well. When do you think humans will set foot on the Moon again? Oh, I said within 10 years. Interesting. Maybe within eight years. And why space? Because I want to go. All right, great answers. John, where can people find more information about you and JP Aerospace? If they want to keep up to date with you. I try to post pictures on our Facebook site every day. I get to our blog and you search for us JP Aerospace on Facebook. We also have a Twitter account that we post about every other day. The blog we post at JPerospace.com right across the top. Click on the blog. I get to that about once a week.


The floor may not be a robot. Toy Story is one of the greatest movie series in the world. I loved it growing up. I loved Pixar movies since I was a kid. However, there's something that I've been demonstrated from that I think I might feel comfortable telling you. I was browsing on the web, watching YouTube videos, and looking on Google images of Toy Story, etc. Until I got a mail notification on my laptop saying I got an email from Pixar. As I opened the email, it said, Dear biggest Toy Story fan in Australia, we have found a very dark deleted scene of Toy Story 2. A former Pixar animator was fired for adding this in a film for children and his taste in horror films, so we dropped it out and replaced it with a better one for children. Only watch this at your own risk. The Pixar team. I was very surprised and confused. How did they even know me? And how was their deleted draft of Toy Story 2? But I accepted the email anyway. The file name was, Toy Story 2, Woody's Nightmare beta.mov. So it was a deleted version of Woody's Nightmare from Toy Story 2. I used to be scared of that scene when I was little. I thought. I opened the file, and it had a message before the video started. The is deleted scene of Toy Story 2 has been changed and will never be seen by the public. The is disturbed and clip is not for the faint hearted. Viewer discretion, is advised. Moving right on, it showed a shot of Andy's house at dawn. When it cut to Andy's room, Woody was on the shelf sleeping that Andy's mom put him on after Andy accidentally ripped his arm. Just then, the Davis' car rolled in through the window, getting Woody's attention. Andy hooped, as heard in the film itself. Woody asked himself, noticing Andy. He then looked down at the rest of the toys and calmed out. Hey, everybody! Andy's back! He's back early from cowboy camp! On the ground were Mr. Potato Head, Rocky, Slinky and Rex playing cards, getting Woody's attention. Ham, next to the door shouted. Places everybody! Andy's coming! All of the toys scattered around the room to find their usual places. Woody heard Andy's footsteps approaching upstairs so he became motionless. Andy burst into his room, riding a wooden hobby horse humming the Lone Ranger theme as usual heard in the movie. He then stepped up to the shelf and spotted Woody on the ladder. Hey, Woody! Did you miss me? Andy said his usual dialogue in the film. He then snatched Woody off and swung him around until he stopped and noticed something. Oh, I forgot. Andy moaned, noticing the rip on Woody's arm. You're broken. He said as he tugged at the arm. Andy then moved Woody away from him and said his same line from the film, but it shifted to a distorted filter like heard in foreign dubs of the scene. I don't wanna play with you anymore. He fell on a pile of cards that the toys were playing earlier. It then went to an empty sea of flying cards, but the background was in a shade of crimson red rather than the gluteal background. Woody then fell through a larger card, but it was ignited in flames. What am I watching right now? I said under my breath. Woody then fell through a spotlight and into an empty dustbin. It then cut to a shot of Woody lying in the dustbin full of mismatched toy arms as seen in the movie. However, the arms were faintly stained in blood. Woody regained movement and noticed he was in the dustbin. He jumped up and out of the dustbin to run. The arms then extended like a tentacle and shot at Woody, grabbed him by the ankle and pulled him into the air. They swung him around the anti-dark area before Andy's distorted echoing voice said offscreen. This is your new home. I hope you have a good time there. It showed a first person shot of Woody being flying around as he can be heard screaming. It cut back to Woody continuing being swung around until the arms flying him down to the bin. It showed another first person shot of Woody falling into the bin as a hole opened up. He landed on a rough ground. The floor was tiled in black and white. He put his hat back on and went to look around. A voice whispered. Woody darted his eyes around frantically, wondering where that voice came from. It showed a shot of a back view of Woody. Just then a mismatched arm then popped up out of nowhere and wrapped around Woody's neck to strangle him. I can hear Woody choking watching that horrible scene. More mismatched arms raised up in front of him. A broken tire which means that we don't function properly. You are one of us now. We always obey the master who throws us away. The toys whispered, revealing to be the mysterious voice. A dust came then grew from the ground around Woody and more arms sprouted out around him. Pleaded Woody, as heard in the final film, as he tried to unclasp the arm around his neck. The arm just clasped back onto his neck, and the arms started pulling him down the dustbin, as Woody's jokes could still be heard.  Andy said sadly, echoing through the dustbin, as heard in the film itself. It showed a bird's eye view shot of Woody getting pulled down, as he was almost submerged in the pile of arms. Woody cried. Andy then closed the lid. It showed a black screen after he did that. I was expecting something else to happen. Just then, the silence was interrupted by a screen that belonged to Woody. The screaming continued until it showed an image of Woody lying on the ground motionless.  Side note, toys cannot bleed, but the blood obviously came from the arms since they were bloodstained. There were screens fading in slowly as the screen zoomed in on his face. But not long after, it showed a scene that came from the final movie, Woody's screaming, waking up, which frightened me, and gasping for air, right before the scene he met Weezy. Then the video ended. After seeing Woody's corpse, I rushed to the bathroom and vomited straight into the toilet. I posted it to YouTube, so I deleted the file so no one could have their childhoods ruined. I've had a lot of nightmares about that video clip, I've hallucinated Woody's lifeless face staring at me. The animator who made that scrapped animation of Woody's nightmare from Toy Story 2 must be sued. I haven't watched a Toy Story video, nor looked up an image after one I just saw.  Never ever clicks suspicious links of deleted scenes from any movie.


This is Cloud ABI talk. Just make sure you're the right ones. Yeah, so we have Alex Wormer speaking to us about the securities on politics. Greetings, everyone. Thank you for coming to this briefing on the inquiry into the Soul III defeat 20 cycles ago. Contents of this briefing are classified duchess royal bloodline. Anybody who does not have that classification must leave the room now. Okay, with the formalities over, we can begin. My name is Alex Wilmer. My mother was Susan Wilmer. She was chief of docking during the Soul III harvest 20 cycles ago. It was her that allowed that fateful ship to dock. Scout ship TLV 3495. The one that we'd presumed destroyed aons ago. This was the ship that was carrying two human cable repair engineers. Those cable repair engineers were carrying their Jolly Roger super weapon. That led to the destruction of the entire fleet and the loss of the Soul III harvest, along with nearly a billion mines. I've been part of the team for the last 15 cycles, investigating the reasons for this defeat. There were many contributing factors. Our synchronization signal impinged on human communication bands. They were able to detect this and from this calculate the time of harvest. This resulted in their human leaders surviving the initial harvest attack. There are numerous smaller incidents, such as trainee GX firing on a human welcome wagon. We've seen such attempts to communicate before. They've of course never been successful, but in this case, critical seconds were lost in confusing the humans and they were able to escape the initial fireball. Another example I would like to highlight, following the initial counterattack by the humans, which was of course futile. Their kinetic weapons, their missiles could not penetrate our energy-based shields. But in one case, a downed ship did lead to the capture of the pilot. The pilot was taken to the human leaderships, where a pilot was tortured, interrogated, mind probed. During this, the pilot did reveal our negotiating position, our harvest tactics, and our general disposition. This resulted in counterattacks by the humans of a thermonuclear nature. Of course, this was a still futile. But they were contributing factors. Finally, there was one more that I'd like to highlight. The captured craft was not challenged, was not questioned when it approached our main harvest ship. This allowed it to gain access to the command carrier. This allowed the humans to gather intel on our initial invasion plans. None of these pale in significance to the principal reason for the Sol III defeat. Capture of the scout ship. From this capture, the humans learned of our existence. They learned of our biology. They learned of our technology. Critically, they learned of our UNIX operating system. From this unit, from our technology, the humans went on to develop various things. Human code words include Roswell, Area 51, UNIX, Bell Labs, ARPANET, AOL, email. All of these are pale imitations to our consensus net, of course. But they gave the humans a critical foothold into our protocols and systems that allowed them to upload a virus to Reclamation Pump 369282. That Replication Pump then communicated on consensus net, spread, sent commands, fleet-wide, resulting in the disabling of all protection fields. From this, the humans were then able to use one of their primitive thermonuclear devices, destroying our carrier ship. Our thoughts, of course, go to all the families of those aboard. So for the past 15 years, we have been carrying out the investigation. There are numerous lessons that have been made in procedure and command decisions. This briefing will concentrate on some of the technological implications. We find that the root cause analysis, Pumpmon running on that pump was vulnerable to the humans' attack. That is how they got their foothold. That is how they were able to instruct all defense fields to switch off.  The problem with Pumpmon was not a simple buffer overflow or stack-smashing attack. The problem was more architectural. Pumpmon had numerous capabilities that it did not need in order to fill the role of monitoring that pump. It could read global files. It could monitor processes. It could create network sockets to other places on ConsensusNet. All of these were unnecessary, and all of these were exploited by the human Trojan. The table you see is a quote from the report. Please refer to that if you need the full details. So the architectural flaws of UNIX boil down to discretionary access control. That is, access control is not enforced by default. There are things that are open that do not need authenticated access. This means that programs on UNIX systems start with excessive capabilities, and once compromised, programs can acquire further capabilities, simply by opening them. There are global resources and global states throughout the UNIX system. This obstructs running programs securely. It obstructs writing testable programs because tests have to try and inject these normally global resources inside a restricted test environment. It obstructs writing reusable programs because these programs assume a full UNIX operating system, and it is very difficult to audit them to say what do they actually use. System administration just does not work at harvest fleet scale. Beyond a million nodes, we just do not know what these systems are doing. Our team would like to propose a human technology that has actually been adapted from their reverse engineered version of our UNIX. This human technology is called Cloud ABI. It is a relatively recent invention for the humans, approximately two years old. Under Cloud ABI, programs start with the ability only to spawn threads and to allocate memory. Unless they are provided with external... Unless they are provided with access to external resources, they cannot access them. They cannot acquire further ability. They cannot acquire further access to external resources. They can only do that through the capabilities provided to them when they are started. The implications of this are it is safe to run an unknown Cloud ABI binary if it is given no resources. The worst thing that it can do is allocate too much memory and burn through CPU. As a result of this, with explicit capabilities passed into the program as a startup, it is much easier to audit these programs to say what they need. As a consequence, it is much easier to test these programs. This leads to better release engineering and could allow for higher level orchestration the ability to migrate processes between hosts rather than virtual machines or containers. This could lead to more efficient resource use in fleets and certainly to more secure resource use. To give you a bit of background on this Cloud ABI technology, it was initially developed by a human in... a human called Ed Schuten. He is located in the European continent. It was initially for the human derivative of our Unix called FreeBSD. It is now available for multiple human operating systems and is compatible with our SenseNet and Cloud A... and original Unix. Some of you may be familiar with a human technology called Capsicum. Cloud ABI is derived from this Capsicum project. In Capsicum, processes initially get access to global resources and can acquire further resources just like any other Unix process. But a Capsicum process can call a function called CapEnter after which syscalls that allow it to acquire further resources are blocked. They return an error and or result in the process being killed. This allows for more secure processes after they have left their initial startup phase. The problem with this Capsicum project is that integrating external library into a Capsicum process causes runtime errors, strange behaviors, highs and bugs, because a library buried deep in the call stack might try to open a file, might try to initialize a pseudo-random number generator from a device and then fail and fall back to a less secure method such as the time of day or the current PID. The innovation that Cloud ABI takes is to make Capsicum default. It is always on. Cloud ABI processes cannot call open. They cannot see global resources such as process tables, file systems or user databases unless explicitly given access. To give you an idea of what we remove, all of these APIs are unavailable to a Cloud ABI process. The first category is simple common sense. These are APIs that were not greatly designed in the first place or they tend to result in buffer overflow bugs. There are thread safe, buffer safe alternatives already available for both Unix and Cloud ABI. The second category is basically the Unix file system. On a Unix operating system, a process can open or attempt to open any file by its path. This is impossible in Cloud ABI. There is no open function. There is no static function. There is no get PID. There is no get UID. Next, we move on to mutual state functions. These are ones that tend to have an effect process-wide regardless of whether a process is multi-threaded. These are removed because they make programs harder to reason about. Removing them simplifies the API and there are thread safe alternatives. Standard in, standard out and standard error are also removed simply because they are a global resource that should be explicitly declared. ARGV is also removed. The method of parsing in arguments to a Cloud ABI process is incompatible with ARGV which relies on acquiring resources based on string values. This is disallowed. After removing these things, we add one simple concept. Unix file descriptors become capability tokens. These are the tokens by which a Cloud ABI process acquires all resources. All APIs in Cloud ABI that allow acquisition of new resources require an existing file descriptor to be passed in. A file descriptor might describe a directory, a file, a socket, or even the handle to control a sub-process. The second thing we add is a single application binary interface. This means that a Cloud ABI process once compiled on any Unix system, native or human, will run on any other Unix system without recompilation. The ABI is available for the following human systems, FreeBSD, Arch Linux, Debian, Ubuntu. It is even available for their Mac OS. The support is in progress on the Linux's, but with the next release of the human's FreeBSD, it will be a native feature. So it's best at this point to illustrate with an example. We'll be taking a very simple, naughty case of a Unix utility, LS. This takes the name or the path of a directory and prints out the names of the files and folders inside it. This is a very simple example. Strip down to illustrate our differences. You will note that the process is taking in a string and assigning it to the variable derpar. It is then passing this string down to the operating system and the operating system is acquiring resources on behalf of the process. If we did not see the source code of this process, we do not know what it would be capable of. It might list the directory, it might list the directory and send those results back to the humans for further analysis. It might encrypt the contents of the directory, it might delete them. It could do any number of things we don't know without fully auditing the source code. Using some of the features of Unix, we can come closer to a cloud ABI design. In this one, the LS program does not take any string input. It receives only file descriptors. File descriptor 0 is the directory that we are trying to show the contents of. File descriptor 1 happens to be standard out. Given this model, if the program was unable to pass strings to the call to open and the call to list dir, we could say that this process was not able to do anything other than act on the resources we provided, namely, read only access to a single directory and everything below, and write only access to a single file stream, namely, standard out. The problem with this model is that it becomes very inflexible to pass in file descriptors in the exact sequence that they will be used by the program. So, the cloud ABI system relies on a new mechanism called arg data. In arg data, there are a set of APIs to gather file descriptors according to a tree structure. Programs can acquire these by key name as lists or file descriptors or maps. In the example you see, we use a helper program called cloud ABI run to map a YAML file containing a description of the input to the program to the file descriptors that the program will receive. In this example, the Python executable is not a Unix executable, it is a cloud ABI executable. Therefore, during the build of this Python executable, any reference to standard in, standard out, standard error, the C-level function open, the C-level function stat, the C-level function opened would have resulted in compile time errors. As a result, we can safely say that this execution of this Python script cannot do anything except read the contents of a single directory and write the output to a single file descriptor. This makes this process safe to execute without trusting its source. We need only know that we have exposed the inputs we provide to that program. The inputs are explicit, not implicit. A further example, it should be mentioned at this point that this example is, at the moment, hypothetical. The Python port to cloud ABI is in progress. It cannot currently do this. Other programs written in, other C programs are fully ported and there is a cloud ABI ports set of packages available. To give you a further example of illustrating what might be possible, we show here a example configuration for a web server. The web server binary itself would not have its own configuration file. It could not read that file unless provided and that file would contain strings referring to paths which the web server would not be able to open. So in this example, we combine arguments and configuration into a single file and this file is provided to the cloud ABI run helper in order to acquire resources on behalf of the web server. Where this web server compromised, it could not start listening on new ports. It could not open a network connection to send the contents of any acquired data out to the world. All it could do is serve network traffic on the socket that we have provided. So at this moment, what is... So at this moment, we ask what can we do in the future with this cloud ABI system. We might imagine a future where software appliances can safely run customer provided plugins or third party plugins without exposing the internals of their system or the entire operating system. These plugins will be provided with a limited set of file descriptors and would therefore be constrained in what they could do to affect the outside world. We might use this to isolate vulnerability, vulnerable systems such as pumpmon or transcoding libraries for security cameras from fleet-wide security systems. By this means we could avoid problems in error-prone libraries such as the human library image magic or the various video encoding libraries that have extremely complex input requirements and as a result tend to have many vulnerabilities found. We might imagine the ability to use cloud ABI in order to implement the human system at Amazon EC2 without the overhead of virtual machines or containers. Similarly, we might imagine the human system Google App Engine with the ability to submit programs written in any language, C, C++, Rust, assembly language. In theory these would be safe languages to implement programs in and allow them to be uploaded to a third party cloud service without virtualization. This would allow us to compose applications, not containers. I shall now show you a brief demo of what has been achieved with the human language Python and the cloud ABI system. Of course it would help if I showed this on the right screen. In order to run a cloud ABI program on this system we can use the cloud ABI run helper. The Python binary you see has been compiled against the cloud ABI system headers and version of libc. The Python binary itself cannot accept standard input or write to standard output. So the file that we are providing is going to the cloud ABI run program which is a Unix program. It is opening resources on behalf of the Python binary. The Python binary is then receiving file descriptors. The contents of that YAML file look like this. At the moment the Python binary is a work in progress. This is the first thing that got working with it. We have transliterated the native Unix Python arguments into YAML keys and the command is given verbatim. We are also able to execute system calls. In this case the Python script, the Python binary, are burning CPU and then printing the result out to standard error. As a result of cloud ABI though this is the worst that this process can do. We can kill it and know that it has done no damage to the system as a whole because it did not have access in order to do that damage. If we have a look at the contents of resource.yaml we see that all it had access to was read-only access in order to import its standard library, write-only access to the standard error file descriptor and the ability to execute a simple syscall. Work will continue on the Python port to the cloud ABI system. There will be a sprint running at the human event EuroPython 2016 on Sunday. If you would like more information please visit these addresses on the human network. Our usual tabs are in... Our usual network tabs on their networks are in force. Thank you very much. So we have some time for questions. Let's start with you then. Hi, I'm Guerny. Thanks a lot for the talk. Hail the Queen. Okay, awesome. So I'm wondering, you know, we have in the community like a lot of tools that attack the same problem. We have app armor, we have things like OpenBSD and SA Linux from NSA, no backdoors, I promise. So why another system? So the problem that we have found in our experience with app armor, SA Linux, such systems, is that the incentives with them tend to be wrong. It is not the creator of a piece of software that configures those systems. It is typically the distributors and the system administrators. So as a result, the configuration of the protection system, such as app armor or SA Linux, tends not to be in sync with the requirements of the programs that are running. So all too often, administrators in the midst of battle on a fleet ship will typically just turn them off. More so within experienced administrators, but even seasoned veterans of multiple harvest campaigns have been known to switch these systems off when there is incoming fire. Yes, okay, another question if I may? Okay. So is this thing production ready? What's the overhead and what is the biggest app you are currently running with it? The system is still in its early phases. It was conceived approximately two Earth orbits ago, around two and a half cycles, until the creator has been working on it quite a while and is an experienced developer as humans go. The Python part of this is most certainly not production ready. It would be tricky even to call it alpha. Unfortunately, the human responsible for its development, some inconsiderate human gave them a job. So there was not time to complete it before this briefing. Hi, thanks for the talk. I'm curious about the support for binary libraries like BCBOX. Are they planned to be art to the Cloud ABI support? And we have seen a pattern common to follow by humans. And they tend to use Linux a lot and avoid free BSD. They security focus tools. And we are also seeing a proliferation of a new tool called Docker, who is taking a different approach to security. It's the acceptance of Docker threatening the future of Cloud ABI. Are we investing time in Cloud ABI when we are going to face a different problem in the next harvest? So I'm pleased to report that the next harvest fleet is on its way to Earth and they will pay for their treachery. The human technology Docker provides similar benefits to Cloud ABI. It has slightly higher overhead and is restricted only to their Linux operating system. The Cloud ABI for Linux support is 90% complete. It lacks integration with their distributions at the moment. We are working to improve this. What was the other part of your question, please? Oh, so there is a repository available of human derived software called Cloud ABI ports. Over 100 packages in this. I do not believe that Busybox is one of them. The Cloud ABI model is better suited to long running daemon processes than to interactive use. It can become quite unnatural. It can be cumbersome in order to provide all the file descriptors to Cloud ABI binaries in interactive use in a shell. So that is possibly a development but if you wish to see if a package has been ported I recommend visiting the Cloud ABI ports link that was included in your notes. Any other questions? All right, thank you very much.