 So the claim is we are live. All right, so. Hey everybody, I think we're live. I think this is happening. This is the second T2 public meeting. What we're trying to do today is talk about, you know, these ideas are very radical, very experimental, very crazy. And we're trying to figure out how better we can explain them to a range of all kinds of different audiences. And so we have three guests. I have three guests with me today. We have comments coming in on the YouTube live stream that we're going to try to pay as much attention to as we can. We've got Andrew. Hey, Andrew. Hey. And Spencer. Hi, and Alan. Hello. All right. So, if you've been involved with the chat room, the Gitter chat room, then you've seen all of these names before. But what I thought we could do first is maybe just briefly sort of go around the room and have people just sort of say whatever they want to say for a minute or two. With a bias towards, you know, how they come to understand this stuff, how they explain it, how fail to explain it, whatever it is. And then we'll just open up for general discussion. So, Andrew, why don't you start. Sure. Yeah, as far as how I got to where I am, which is, you know, probably in the good double digits of percentage of understanding this stuff, which is, you know, I'm going to call that an accomplishment. You know, I think it was kind of, it was definitely kind of slow for me, you know, I'm a software person, but more on some of the high level stuff. So my computer science background is not super thorough and just immediate to pick up. You know, the process for me, I think seeing you talk the first time that was that was the hook, right, for me was was seeing your talk and you explain it really well. Going through, I think the starting with the conclusion in all of your presentations, you know, really helps set some context. So as far as sort of the jump to the end of this, you know, I think that strategy is a really good way, you know, just summarize everything and try to get somebody sort of, you know, building the world in their head. And then you can start to sort of focus it right and bring the detail in that that seems to, you know, resonate, I think with a lot of people that you talked to. But you know, then going to some of your websites and the like the robust first wiki and all of that, like those pages used to kind of scare me. I'll have to admit like, you know, not quite understanding it, but then sort of little bit by little bit picking it up, watching any other videos, the demon horde sort obviously is a really, you know, popular one and I think easy one to get into, especially if you do come from like any sort of software engineering or computer science background where you remember your data structures classes with, I don't know, probably bad, bad sort of nightmarish finals and that sort of thing. And then it brings back those types of algorithms and you see this thing that's sort of really brand new and different. And I think it's very intriguing. Like it's, I think that the thing that all of these concepts have going for them as maybe complex or hard to understand as they are, they can hook you and you can kind of follow them along and be okay with not really understanding. It's sort of an adventure to get there. And that might be something to also try to exploit or, you know, say, you know, just in general like this is kind of complex stuff, but it's also kind of exciting. That's sort of the overall feeling that I think that there is to capture and to spread. Okay. All right. Spencer, talk to us a little bit. Yeah, I kind of have a lot of, you know, comments that are similar there to Andrews, just in terms of not really having a solid background in terms of computer science, I mean, I kind of come from more of a system administration system engineering type. And that's only recently. So I kind of stumbled into your YouTube channel by accident. You know, a demon or sort, I think is kind of one of the ones that really helped me to grasp exactly what was going on or, you know, kind of closer in that direction. But, you know, I like what you said about the sort of layers of complexity there, because there are some parts of it that are deceptively simple, like the dynamics of drag and res are pretty easy to comprehend, you know, how that's actually implemented in hardware and, you know, how that relates to law and splat and simulator. Those are all things that that require a lot more depth and a lot more documentation and more, you know, research and that sort of thing. And that's one of the kind of materials that, you know, I'd like to be able to have and provide to folks as I'm explaining why I why always so many hours looking at this sort of stuff. Yeah, like how it how dragon res relates to Excel spreadsheet. There seems to be sort of a conceptual gap there. Alan, how does it look to you. I never know what to say in these sort of things, but I, I kind of came to David's videos on YouTube. If you haven't seen them, I definitely recommend that they're pretty interesting from someone who does feel like they have a good four year computer science background like I think even the ideas that are come up in David's videos are very different to some of your points like it's probably okay not to understand it because of how different they are. So just just think of like robustness is something that we talked about a lot like in computer science education usually learn about efficiency in terms of time and space. And the idea with, you know, the one of the sorting videos, for instance, is that in a sense, you know, bubble sort is something like really stupid and computer science but it's somehow in another weird way one of the best sorting algorithms, because of how state the stable and because of because of how stupid it is how stupid it is. And I think to be said about that like, how do we create systems that can withstand the test of time and space. And that is somehow robustness, robustness is the answer to a lot of things about how to make computers less bad. You know, we see like today we rely on computers for almost everything and just saying that is pretty terrifying. You know, they're not the best mediums for expressing things exactly and perfectly and that's what they try to be. So it, that's, that's a little frightening. So we should think that we should think back to, you know, the basics of how to build a computing stack that can work better for for everyone like work, work in a way that doesn't require exactness that doesn't depend on on its perfect programming that is so elusive to everyone who's who's ever tried to program anything bugs, bugs happen all the time. That has to be all right somehow. Like watching the videos is a great start and trying to form your own ideas. You're definitely touching on like one of the core intriguing pieces, which is just sort of like, well, what if it's not about efficiency. And that just, I think if you, if you, if you say that to somebody who never really considered it and I would say most of us not having gotten into these concepts never really considered it in the first place. It's sort of a jarring question. Right. It's sort of, well, what do you, what do you mean? Like it's all about efficiency, right? Yeah, like, you know, we, we do okay in efficiency today. Like the fact that we can do billions of things a second is amazing for society and for computing. But then security comes out of nowhere and blindsides you like you can do things fast, but you can you can change a single bit and now everything is completely messed up. Like you get vulnerabilities are everywhere too. So that's another angle here. For sure. Well, so certainly, and how you know there's that idea of like the sort of pinhead business manager who wants to come in and micromanage everybody to make business more efficient. And, and everybody, you know, would like to hate on that guy. And, but when it comes to computer science, it's not that the efficiency guy doesn't doesn't look like this busy body that everybody hates. All of a sudden it's a good thing. And I wonder if it would be possible to, you know, visualize that that small minded, very narrow focus on efficiency to help explain these ideas to help put the people who are yacking on and on and on about how their thing is, you know, into the 1.735 instead of 1.738 efficiency, or whatever it is, into some kind of context as the, you know, the computer security bugs and malware thieves are just driving by them on the freeway. You know, whatever badness they could do something like that. So certainly I think there's the dual view of efficiency as something good, and something maybe, you know, with unappreciated costs put it that way. That is one angle into this stuff. And one of the problems that I feel I have presenting this stuff is that I try to make it simple. I try to come up with simple ideas and metaphors with the net effect, I think that people think it's, it should be easy enough to understand that they should understand it in five minutes or eight minutes or 15 minutes, whatever it is. And the only way to get it mad amount of time is to misunderstand it. The only way to get it mad amount of time is to say, Oh, you must be talking about multiple. You must be talking about, you know, some other thing that they already know, like that. And certainly that's one thing that came up a number of times when at pioneers in Vienna last week, when folks would come up after the keynote and say, Oh, I was inspiring was fascinating. So you're saying blah, blah, and then and then it was like, well, that has the idea of doing something more than once but really it's a more like that, and so on. And one thing I wonder about is, if we say there's no way to get it immediately, there's no way to expect someone to get it, you know, the whole of it right off, whether there's some kind of little staging, maybe two or three things that we could figure out a way to say, Well, for this kind of person, it ought to be computer security is really bad. It's caused by efficient focusing on efficiency without taking bigger considerations into concern. And there could be another way, but for somebody else, it might be CPU clock speeds aren't speeding up, we need to go parallel. And suppose we could just go parallel forever, I don't know, whatever it is like that. That there for for everyone because a distributed system could also be faster to like, it could also be eventually faster. That's big enough. Right. Sure. The air computation. Right. Well, you know, air is a rate and if that's not enough computation for you plug in some more, you'll get the same air. So you were just in, like, just to say like, you were just in Vienna, right? Right. How did that, how did that go? Did you like present the new Bab and all that part of that? So, so there will be apparently I spoke to the the pioneer folks and there will be video. So that'll be up probably on the regular Dave Ackley channel, but it's going to be a couple of weeks for some reason. So it'll be on that time scale. But as far purposes here, the, the one thing I tried to do was to give them a, you know, forward take away that if you only get one thing out of this talk. It's this hardware determinism must die. And Elena didn't like that because it was kind of negative. Yeah. And it should be a positive thing and so on, which I'm the one hand I agree with and I agree that being negative. What must be born in its place is the right. Right. Like that. You know, every once in a while, you know, punch a Nazi in the face and just really drives the message. Just say everybody should love each other and flowers and so on. Like that. So, and that was my attempt that was my new attempt for the pioneers talk to try to boil it down to people who just remember those four words. You know, and then of course, you know, someone comes up to me in the break room afterwards and says, Oh, you're saying card determinism is good. Something like that might be, might be pretty punchy and effective. I can see how that would work. Well, well, you know, it worked to a degree, but not as much as one might think. The challenge is what do you, what do you do? If you don't have hardware determinant, determine, you know, what do you do and what what is in its place really. Right. And the reason I like that is that, you know, that that really seems to put the blame where it's supposed to be. And if you say, okay, hardware determinism is dead. And just as you say, then the response is now what? And say, well, yeah, but you know, you know, welcome to the party. And so we'll see about that. I don't know. Is it obvious what the more positive forward version is? Well, you know, I think, I think it's, it's actually just watched rewatched. And it's been a long time, the matrix. And there's that famous scene, you know, where Morpheus sits down in the chair and, and, and gives his speech about there's something else. And if you want to go with me, take the red pill, if not take the blue pill. I feel like there's that there, there's an opportunity because this thing is like a whole new world. You know, instead of sitting down for four hours and describing the new world, just say like, look, you want to jump in and go for the ride. Like, like, you know, I think there's that opportunity. And then it also makes me think about like, well, that scene in that movie, that happened sort of like after, you know, hundreds of people had already kind of gone through this. And Morpheus was like, I've got this in the bag. I know how to do this and all that. But imagine like, what was Morpheus's like, you know, Google Hangout, YouTube live stream discussion about how do we get people to come out of the matrix? You know, that's what this is right here. Like we're trying to figure out, like, well, hey, you know, if we, if we build these pills, you know, and make it a really easy choice, we'll get the people that we want to be in this new world with us and the people that aren't ready. Well, they can come back later, you know. Well, certainly the thing that I like about that, aside from, you know, being a permanent Matrix fan, is that the all that is being offered is the beginning. So it's not trying to give you the whole answer. It's not trying to say, here's the whole thing. In fact, it's explicitly rejecting that by saying that the whole is going to blow your mind so hard that all that can really be done to begin with is to make the choice. Do you want to blow your mind this hard, or you want to go back to CPU and RAM or something like that. Now, of course, you know, Red Pill and Blue Pill has been kind of repurposed by a number of different strains of folks these days. But I don't care. I mean, you know, it's, you know, Charles Manson's dollar from the Beatles and we're stealing it back. That kind of thing. So I think that's great. I think that's a one good avenue to pursue both because of the idea of just, you have to choose about making a beginning number one, and number two about just kind of the Matrix concept, which is this, you know, spatially extended 2D, well, 3D computation. Which is, how would you actually implement the Matrix, you would do something like the Moogle Feast. It would have to be something like the Moogle Feast to implement the Matrix at any sufficient scale to be able to do anything. That's a good jumping point, Dave, is you talk about like the things you, you know, you talked about in terms of the bespoke physics and stuff. Do you think it's difficult after you convince people to maybe reconsider hardware determinism to then consider a bespoke physics on top of artificial life and accepting one radical idea, plus another might be a little too much for some new people who, you know, I mean, it's, well, I don't know. I mean, that's the on-boarding thing. I mean, there's going to be a set of, you know, where you think, okay, let's give up, we'll have a few little errors in the hardware. So then maybe we'll have to, when we do an operation, we'll have two copies, we'll have three copies of it and they'll vote. And then I think, okay, and the operations can still be Excel spreadsheets. But I'll have three Excel spreadsheets and I'll compare the results with Diff or something like that. And then everything else is fine. And I suppose one problem that I make is I want to rush on. I want to rush on to the, oh no, that's not good enough. We have to do much more than that. We have to blow up the spreadsheet. We have to blow up the everything. And it would probably be smarter to say, yeah, like that. Having three copies of the spreadsheet is redundancy and redundancy is important. Exactly how we deploy that redundancy. There's many choices and blah, blah, blah. I don't know. Well, so if you have any experience or stories, I am curious to hear how people misunderstand you when you try to say these things or what seems to work, and what seems to be helpful as far as how to explain stuff in people's experiences. Does anybody have any thoughts along those lines? Like an anecdote about explaining the project, I usually just get, if I start from the hardware, I usually just get as far as explaining this new kind of hardware where you connect together in this large, large matrix of connected things. If I start from another point, I usually don't get too far, honestly. That's not a small discussion. I have talked to biologists about this, and I think biologists are very interesting people because I think they're cautious about certain analogies to life-like things that aren't precisely like real-life examples. Like they might stop at some comparisons that we make to life that aren't exactly as RNA, DNA-based life that they know and work with that all the time. I think when you say artificial life to biologists, it means something much different. Yeah, well, there certainly is that, and one little anecdote on that. In this talk in Vienna, there was a person introducing the keynote, and they were supposed to set it up with a question. And they say, you know, and then here to talk about that is Dave Ackley from the University of Mexico, whatever it was. And so we were backstage like, you know, an hour before the thing, and the person that was going to be introducing me says, you know, so here's the question that I'm going to do. And the question was something like, you know, is it possible to create artificial life that will be living here among us or something like that. And so they were the interpretation they went with was, you know, like physically creating meat machines that would be running around there of some sort, not necessarily humanoid, but made out of the stuff that were made out of and so forth. And there wasn't even a need to like check with me that that's what I meant by artificial life. They were just going with it. And because it was self-evident that that's what artificial life must mean. And so we had a little discussion backstage and I said, well, you know, you could say that it's not exactly the kind of artificial life that I'm working on. So we worked on a new opening question that ended up being something like, you know, people talk about computer viruses. Is a computer, is that just a metaphor? Or could computer viruses be literally alive inside? That's cool. Here to talk about it is they were like that. I think that definitely gets the imagination going on this gray area of life for sure. And so something like that, which again, you know, because I've been working in artificial life for so many years, and we have this explicit, you know, there's three different kinds of artificial life hardware, software, wetwear like that. And the fact that I'm talking about the wetwear that she was talking about wetwear, the person that was introducing us. And I was talking about the software one, you know, the fact that that needs to be answered was clear. Anyway, go ahead. Spencer, we haven't heard from you. Do you think there's other angles that we need to be thinking about? Well, I mean, I think, you know, I really liked one of the points that you touched on about how if you're going to implement something like the matrix, it would have to be in a computer system like this. I think what you touched on is kind of one of the distinct advantages. And that's, you know, because for me, if I'm explaining this to someone, they're usually some kind of engineering type. And the idea of redundancy is just that's part of it. That's part of working with machines as we have them because you can't trust one. You need 10 nodes. And if one of them misbehaves, then you take it out back and, you know, the deed is done and you get another one and you keep going. Wow. And, you know, as far as, you know, you have to replicate data tons of times all these and and really that's kind of how I came to, you know, I was looking for information on stuff like that. And one that I ended up with was finding Dave wanting to, you know, destroy the whole thing and build it back up again a different way. I feel like I should apologize. No, I'm glad you did because it, you know, gave me the perspective that it really doesn't matter how many, you know, containers you run, what kind of orchestration system you use. They all still have the same fundamental flaw. They're limited. They can't get any bigger. You know, we can do 128 bits of memory address space, but then that's again, that's where you have to stop. So if indefinite scalability is a base requirement for your computation, or if robustness at an architectural level is a base requirement for your computation, and this is the kind of thing that you have to do. You have to build this body of knowledge. How, you know, how do you handle libraries for a system like that, you know, what kind of patterns are useful in terms of how atoms interact with each other. Do we need a bigger event window? How big should the atoms themselves be? You know, all these sort of philosophical questions about a system like that and how you make it work. But I think the idea that from the outset, when you start this way, that you do get these advantages that you just couldn't get with the correctness and efficiency only attractor is what I heard from you there was that you were sort of coming at it from a sort of systems administration or data center DevOps, some kind of framework like that, because you were saying, you know, yes, people get efficiency. I'm sorry, people get redundancy people understand redundancy. And from me coming from the point of view of teaching computer science for 20 years. Most computer science does not get redundancy. So it's already that that's put put you off or that that avenue of introduction, where redundancy is something that's understood is already something which is kind of to me, not even the center of computer science, but it is an important branch of it, because data centers and reliability and the cloud always being there and all that sort of thing is so important to modern life is like that. So I get that. And maybe we ought to be able to be appealing to data center type stuff, people people who are aware of redundancy and that sort of thing, with a pitch like, you know, you know, geez, you've got you've got high availability, you've got you've got live heartbeat sharing, I don't even know what all the techniques are going on. And, and yet, you know, it's all undermined by a stupid security hole inside the campaign, you know, whatever it is, all the things you try to do. It is all just wiped out because the container itself is not trustworthy. And wouldn't it be better if we could just shrink that container, you know, like take that container apart, make it seven copies of something smaller, so that if there's a problem it couldn't propagate as far. And that would be another route. I don't know if I agree that the size of the event window is a philosophical consideration. So it's a pretty specific one like that. But so maybe that's another angle. But I mean, are there other audiences that we could think of that might be suitable for this sort of thing and and how we would how we could try to to pitch it to to angle it for such an audience. I don't know if I have a specific one, but I think that definitely that, you know, just the idea of, you know, much of computer science and the occupations that exist underneath the umbrella that computer science has built. You know, most of those are based on efficiency system so so you know a majority of computer science is sort of established on top of efficiency. And so if you're saying we're going to we're going to replace that with robustness and some efficiency, then everything on top of it needs to get rebuilt. So what does a systems administrator look like in this world and then what are all the other sort of niche places that that seems like the opportunity for that that I see is like this is a whole new world. But it's not just the whole new world that you could like Google for and find all the answers about right. That's that's what's really intriguing about it is, if you want to know what a bigger event window does, like, you get to go do it, and then tell everyone, and then everyone's really excited what like about that, you know, I say, so you're saying like kind of like the low hanging fruit part of it that this is a whole new world of which certainly, you know, return. Yeah, exactly. And that's what attracts me. And that there's there's just brand new questions everywhere. And but again, you know, one of the things about, you know, trying to do a weekly video log and talk to the public and all of this stuff is it makes me realize how tiny computer science is in terms of something that people do. I mean, we're all here and and following the teaching trial project, at least most of us are already really weird for being thinking about this thing. Well, you know, I mean, I'm not saying it's any different for any other little crazy niche specialty, you know, in medieval crossbow maintenance or whatever it is. Like that. And I guess computer science is probably bigger than medieval crossbow maintenance but it's all in the grand scheme of things of people doing stuff. It's all small potatoes in some sense. And the fact that we can explain it to other computer scientists or we struggle to explain it to other computer scientists means you know maybe we need to just try to, I don't know. Yeah, it's not. No, great. Yeah, it's not great. But I mean, I just I just agree a little bit about I mean, I think some of this stuff is in the mainstream, like, I thought of something that based on Spencer said, or, I guess that like a data center DevOps type of person deals with redundancy and things like that on a daily basis and it's part of the job. So I think they would understand something where saying that we need to make things more redundant and robust. I think I think they would understand that and well and I would argue as well that right now what we have isn't very efficient. I mean, because things are so fragile, we have to do thousands and thousands of nodes instead of just having one thing that's actually robust. Yeah, you have lots of containers and in one control plane as well, which is also stupid software. So what if you made each container in an autonomous In all of these systems require people to have pagers and wake up in the middle of the night and go and reboot a machine and replace a demo RAM and things like that because the machine just doesn't doesn't adapt and doesn't grow and doesn't learn from the things that it's experienced before. So self healing is a feature of the control plane not a feature of the individual parts and that's something that is interesting like each part doesn't know how to heal itself if the control plane dies and the whole data center is gone. So there's there's definitely a micro miniaturization of control that that could be cool that cool to communicate as part of the project like we're making control more localized and that's safer. Certainly. So we have a question from the chat room from Scrumzy, how works input output operations in other words, how to get an answer out of computation. How to get something out of this question. Well, well, but the point is, these just because we heard it once, you know, doesn't mean we can be done with it. We have to be working on our answers to it over and over again, and so on. And how fast signal travel time from one teaser to another is a speed limitation. Well, certainly on that. Yes, absolutely. And, you know, as we start building up bigger and bigger collections of T2 tiles. And the fact that it takes a non trivial amount of time for a signal to get from one end of the grid to the other end of the grid is going to be something that it you know that it's going to become more and more apparent but the whole point is, is that we're doing all this spatially local computation in between it as well and the question about how to get to output. And I really want to work on saying, okay, let's let's think of some way that we could take a patch of tile, you know, 50 tiles or whatever seems appropriate, and somehow actually connect sensors and effectors of some sort around the edges, mostly. And, and get this group of 50 tiles to be a signal controller for whatever the sensors and effectors are that that we connect to it, you know, a little bit of a robot of some kind. Like that, just to show how you know even if the overall model is meant to be indefinitely scalable as for engineering purposes we can say well let's rip off about this much of it, and see if that's enough to do system control for this particular little system. And, you know, one thing that so put it this way, once people understand the idea of centralized control CPU sort of single point of failure, do we really want that don't have to get rid of that. Even if they accept that that's bad, and they want to say okay so we're never going to have any centralized control of any kind, then, in fact they've gone too far the other way. Because you need to be having little bits of centralized control in order to make a decision and decide to the robot go to the left or go to the right. And just, you don't want to let the fact that you need some little local centralization cause you to say well I'm going to have any centralization know I might as well centralized everything. And which again is a difficult sort of thing because it means the argument is somewhat nuanced it's neither all centralized which is kind of what we have now at least until we get to the data center. But that Alan and Spencer we're just talking about, and even in the data center once you get to a software defined control plane, then you're back to centralizing the whole damn data center at the level of the control plane. So, you know, from one point of view there's this endless struggle back and forth between distributed member of the team and bottom and top down master of the universe kinds of structures and we need both. But the idea is to not let the master of the universe thing run away with that. Sounds like we still don't have a straightforward answer to that. Well, I was going to say like, you know, again, we don't but that's what's that I feel like you got to you got to market that right you got to say, I don't know what that looks like but if you have ideas come help us figure it out and, you know, Like you can sample sample things with sensors. I think that's a good, a good answer. Well, and I think like Dave was saying that the spatial necessity of having a sensor is one that affects computation that there is a central point for the input of a light sensor or a sound sensor or a terminal or whatever, because physically it has to live, it has to exist somewhere, you know, maybe you could do some kind of random tile selection and select, you know, something in the neighborhood of where microphone input is so that you can process audio signal. But at the end of the day, it physically lives somewhere and that's where the computation needs to occur. I mean, I just works and we don't explain why just said I just works. No, it just works just plug it in. Say that one day. I like the other question as well. As far as like implementations of the intertile connectors and that protocol like what what kind of requirements even I mean I don't comprehend what you have in, you know, what you're leveraging on the Beagle bone green how that interacts with the shield and what kinds of, you know, future improvements or, or, you know, just you can look for if you want to try to implement this in some other way. Right. I mean, one of the things that was good about that, what I would call today the T one tile, the I XM back in 2008 and 2009 was the intertile connectors of which there were four were just serial lines, yours. And in fact, plus a couple of GPIOs that you can use for anything that you want. And there's a zillion things in the world that talk yours. And in fact, the hardware guys that was not me, thank God, who were building the thing built a few extra custom tiles that you could plug into the edges of a grid of I XMs, like one that provided mass storage and one that triple micro USB connectors to plug in normal stuff and talk you arts over them and so on. And the connection, the protocol that we have here for the T two tile is not you are it's like everything else it's a bespoke custom thing that it's actually very simple and it might even be new and it might even be kind of patentable. I just don't know enough about these protocols to know what's out there. So, but on the other hand, really, those it's just for his eight, basically eight raw pants. So if people wanted to make a custom plug in to put in a temperature sensor or a, you know, a whole little robot interface to, you know, control some servos or something like that. The, the, the tightest way to do it would be to have to make a Linux kernel module or possibly user space, flipping those lines if it was fast enough. And just have that corner be configured so that it's not being a normal intertile connector at all. So now it's just being a bunch of pins that the particular thing that knows there's supposed to be a robot set of servos plugged into that edge. That's what they would do. And, again, that's all, you know, down the road meeting the things but on the one hand, we're worse off than we were because we're not talking you are. But on the other hand, we're better off than we were because number one, we have more pins and number two, they're really just GPIOs at the bottom of the program. So what else? What have we not talked about here? So all right, so it's quarter of, so we got a few people watching, not very many, and I guess largely that's, well, that's partly my fault because I had the damn thing unlisted until it is, but, you know, in a purely selfish way. You know, just Andrew and Alan and Spencer, you know, I appreciate the feedback, the thoughts that you've got. I think we always have a long tail of people watching later too. And they could always have a long tail. Hello, hello, later people. Right, right. Yes. I'm sorry, you can't ask a question that will connect now. Come back to the getter or something. So, what have we not talked about? How are we going to explain it? How to explain it? We haven't talked about software, Stag. Uh-huh. So, yeah, absolutely. So what should we say some more? Well, I mean, you know, is this a way to, a way into it, a way to show people something like that, or, you know, it's just a baffling gnarl of compiler bugs and uninterruptible understandable messages or some combination. No, I don't think so, but at least you're stepping forward, and that's really, really valuable. Well, I mean, I think, I guess, first of all, it's just a good time to plug that there are two ad hoc languages for the movable fees machine that sort of take all of the complexity and the, you know, the details of the intertile connector protocol and abstracts all of that away and makes it, you know, what you have at the end of the day is an atom. An atom has, don't let me get any details wrong, 96 bits, and it has an event window or 41 sites, and this is how it has to live its life and do its computation. And, you know, we have splat as a two-dimensional spatial programming language for interfacing with that and Oolong and as more of a, you know, C-like type procedural language and, you know, just how to interface with that, how can people contribute and that's, you know, and then I guess over and above the programming language is what sort of concepts and patterns and things do we need to be looking at with how we design software. I mean, we've tried this once or twice before, but, you know, you talk about like the design patterns book that says, you know, there's all these repeating patterns in traditional deterministic serial computation about how to connect different things together to get jobs done. And I really feel like in the future, there will be a best effort design patterns book that will say things like the key thing about Dreg and Rez is, you know, spatial mutual regulation or spatial mutual homeostasis or something like that. And that would be a design pattern. And another one would be sort of like elect a leader, have everybody and elect a leader and then have the leader suppress all the elections as long as there's a leader there, then nobody else tries to start an election. But if the leader then dies for whatever reason, then after a period of time, somebody declares another election, and we get a leader back again. And, you know, a lot of this stuff in some ways is been studied in computer science in distributed algorithms again, usually with a very limited error model or deterministic thing but it gets at lots of the same stuff. And so I think, you know, I don't know how to actually do it. And, but I think there are a whole lot of best effort distributed design patterns that could be teased out and could be named, and could be spread so that sounds like you're doing a drag legislation or whatever the name happens to you. Yeah, I mean, I think just software stack and then that piece together, like, you know, when I started to really start, you know, it started to solidify these concepts, I really like had this urge to get my hands on it, and I didn't have a Linux machine. And, you know, I tried to like, use virtual box to run it, but it was real slow. I finally got there. And so, you know, I definitely think that there's that, you know, that's what led to MFM rocks is just like it was my own need to like play in this space. And I think I think that's another, you know, another selling point is just like it's almost like a game it's almost like a puzzle to solve and I feel like for us, most of us in this field like we like to solve these types of puzzles and, and even the better puzzle that you can't Google the answer for, you know, like, again, like, it feels important, because you can sort of make something and, and like be really, you know, proud and kind of interested by it like just the it ended up being one of the sort of the dumbest elements that I've created, but the sticky membrane element is so simple, but it does some really interesting things when you play with it on MFM rocks that it's I can just sit there and just play with like, just, you know, kind of marvel at like, Wow, that's so neat. Right. Yeah, absolutely. I think having the MFM rocks, which, you know, shout out, if you haven't been to MFM dot rocks, go to MFM dot rocks, and, and click something on the screen. And, and you'll see what we're talking about. I think that's already been great. And, and like, like, Don Hopkins, who I pointed at your stuff was was looking at exactly that sort of thing trying to have a JavaScript sort of non deterministic simulator and so forth. It also, it seems very much like the sort of sandbox simulators that people write where you have someone's feeding back. I don't know what that is, maybe it's just me. Maybe where you have all these different elements that you can draw on the screen and then they just animate they just do whatever they do. And nobody knows what the thing is going to do all put together. And unfortunately, I mean, except possibly for MFM rocks, the simulator is too slow and too heavy weight too tied to Linux, and so forth for it to literally be an under a framework for that. But MFM rocks kind of is. And, and Andrew's kind of building up this palette of fun elements that you can draw on the screen and see what happens. I think we would hope that things that work on on MFM rocks also work on on that MFM classic so And I would think until Andrew starts, you know, using taking advantage of the fact that he can have arbitrary amount of state per atom. Yeah, yeah, my Adam has a linked list in it. I'm just living in the future. Well, and the wheel of karma says, you know, eventually the atoms will probably start growing bigger again. Absolutely is because the whole point is you get to avoid all the hard issues, which is what we're here to marinate in and say, you know, wow, even though you can only talk to the nearest four neighbors look, we can make this giant structure that not only rumbles itself, it repairs itself. And it does some extremely limited computation like sorting or routing or what happened. Yeah, I honestly, I haven't worked on a project in in a bit, but I have, I have done something like an organized self organizing math once and I think that was pretty interesting. You want to develop something that will work on almost any scale. I think it's pretty cool and rewarding. Once you've done something, a project and, and you know, you see the colors moving around and organizing. Yeah, or cells or cells, like almost like a living thing, like a little, like a little cell pet, right? You've done stuff like that before. That's, that's pretty, that's definitely pretty interesting. Certainly, there's lots of people who play around with artificial life and make little simulations and make YouTube videos and put them up and so forth. And I want to support that as much as I can. Number one, thinking about artificial life and stuff reproducing itself and number two, writing your own code and being in the godly physics of the world that you make and so forth. But beyond that, I want us to be able to be sort of a destination. So when you're ready to take that to the next level, when instead of just trying to simulate dragons and dinosaurs or whatever it is, and you get bored with hand adding more properties to the dragons and the dinosaurs. Because then you only get back sort of about as much complexity as you built in, and not a whole new blooming ecosystem and that's the normal, you know, a level of disappointment that happens with artificial life is you get a little bit of development, but then it doesn't blow your mind twice or 10 times and it only blows your mind nine times and then it kind of poops out. But to say there is another option, and the option is to take the tough, the red pill now, where you say, I'm going to commit to rules, I'm only going to do things that are going to be indefinitely scalable. And then I'm going to be able to take all that thinking in and deploy it at unimaginable scales like that. And, you know, hopefully real soon now, a month or two, we're going to have pretty significant scale, like hundreds of real hardware, yeah, real hardware exactly. And I mean, and I'm definitely looking forward to getting submissions from from Spencer from anybody who's willing to write some splat or whatever and say, okay, you know, let's run your code on 100 tiles. And see what the hell happens now, you know, maybe that'll be three months, I don't know, whatever it is. But well, the whole system administration of just sort of dump some Linux on these tiles, it like, you know, covers a period of things that are non obvious about, you know, every time I need to reinstall Linux on one of these tiles, I have to disassemble the tile. So it's not like I want to do it over and over again, which means I want exactly the software defined control plane that we were just ragging on for the data center. Make centralized control, you know, like Ansible, you know, whatever these things are like that because I have to wrestle dealing with 100 of these things at once as well. So we'll see. The fantasy is, is that, you know, eventually, you know, T three tiles T four tiles, whatever it is, when the technology is mature, it's not like they'll still be a Linux. This will just be custom chips with hardware accelerators for event window operations and all that kind of stuff. And they'll be so cheap and so optimized, and they'll go fast, they'll go 400 air or 300 air or who the hell knows like that. And so the fact that I am building in this incredible security hole, you know, which is, if you can get my private key, then you can, you know, screw worrying about what the Adams and Dreg are doing just reprogram the whole thing and have yourself 100 Linux boxes to send spam with except for except for the guys at the periphery. So I don't know. So I guess we should probably wrap it up in the next few minutes or so. Chat, any last questions in the chat questions. So while we heard from scramsy again. Thinking about the proof of concept demo, something like space computer for keeping life. Okay, right. So that's a good question. So he's saying, should we say that we could use this for even just as a as a as a simple little proof concept. And the suggestion is something for managing a space station or space capsule or something so monitor oxygen pressure temperature that sort of thing. And the good thing about that off the top of my head is, it's really important so you don't want it to screw up like that. And it's in a challenging environment, the space radiation hard environment and all that sort of thing. So you want it to be robust as far as that goes to as well. I mean, you know, certainly, to me, and this is one of the lines that I've meant to say in the Vienna talk that I think I ended up forgetting to say that, you know, what is the killer app for this thing going to be, you know, it's a whole new world. What's going to be the first killer app. I don't know. But what I do know is that it's not going to be about artificial intelligence, at least not directly. What it's going to be about is about robust real time system control. And that you take the whatever sensors you can get and whatever knobs you can get, and you plug them in the sides of this thing and it just sits there all day long, trying to say, you know, am I happy with this is everything within limits is there going on and doing it with tons of redundancy. So half of them won't have enough of them, but if a bunch of them are booting or get shot out or powered down or whatever the thing continues to do robust real time system control. That just kind of just a quick sort of idea to talking about like getting audiences different audiences on board with this is just like, you know, the idea of it being robust and more secure is to have something and even if it's just a little program that sort of keeps a packet of data safe, you know, and in its place and then inviting hackers to sort of say like hey come get this data. Can you, you know, that's Yeah, I'm completely terrified by that. Maybe it's for T3, T4, 12, not for. Break all the rules. Current version but but you could definitely see that as like what you know it to prove out some of these concepts if you don't necessarily have to have a killer app, you just need to show the benefits over the CEO architecture. Right. Yeah. And again, my goal is, is to have some incredibly simple system like a robot. Yeah, we two wheels and two light sensors and try to get it to go toward the light. You know spend $15,000 to make 100 gigabytes of computer power. 100, 100 gifts. Are we committing to the robot thing because I think that's a great idea. All right, well, that helps that helps push me to say yes, yes. Well, well, all right, but I'm going to need help because you know I don't know robot stuff. I don't know how to, I mean, it will be by far coolest if the it was a big platform. So that the brain, this giant sheet of brain is physically on the thing. And the robot has got a couple of car batteries or something like sitting on it. Well, but big, but big as opposed to just having a little toy robot with an extra long cable that's trying to feed data back and forth from the grid. Yeah, like a big radio antenna and that's it something really stupid. I think that would know that like all the all the logic is over here. This is what we're controlling. And you're voting for the cable, the physical separation between the grid and the robot. I mean, possibly. Yeah, I don't know. I mean, I think super, super cool to have it all in the same place. Well, I think in terms of the computation, wouldn't it be interesting to have all of the inputs for the control units in different locations on the grid itself. So like you said, those those connectors, those would be on corners of a grid. Right. And the motor that happens to be at the front left would talk to the tile that's front left. And the bump sensors would be all around the day. You wouldn't want to serialize data and send it over a radio and then control, you know, right. Okay, but that makes it all that much more ambitious. Now we have to make a giant, you know, get a radio flyer wagon or something like that. The whole thing inside it, or whatever it is. I really do want to take that as a target, just because it makes it really obvious that it's about system control and it's about using space as space, so that the sensors like the edge of a starfish or the clams that have all the eyes along the little edge of the thing. I don't even really know how it works. That that's it that we have a spatially distributed computer for a spatially distributed machine, and we wind them up like that. That's pretty, that's a ways down the road. And probably even if we do do that, we want to think towards having a simulation, some little, little toy, robotic sort of thing that we could start playing with it, or play with, you know, staged simplifications of it, before we actually get to that point. Right, then you get into training and moving the simulation into the hardware model and how it's transferable and those kinds of properties. Exactly. Even if it's training us, even if it's training us how to write the code, so that we can get it working, rather than necessarily doing the machine learning everybody. Keeping the expense low for the, for the development process for the developers. Yeah, that's right. Any so I guess we're a little bit over an hour here do we have any other thoughts so how to explain it. So I really like the sort of red pill idea in the sense of expressly make it like this is not a simple idea that you instantly get this is a path that you can begin. But we need to make it a path to someplace exciting someplace that you might want to do it. And I guess, I would think it would be sort of the path to indefinite scalability, the path to, you know, computers bigger than your wildest imagination. And Han Solo saying well I can imagine a lot. Yeah, that's the point. And I think just being able to pioneer something you know it's it's like why do people want to go to Mars you know it's just a bunch of red rocks, but you know it's just because nobody ever did it. Yeah, like that. Well I think that's true too. All right, any other any other final thoughts or should we let this go for today. I'll sit here. Happy everyone joined. Well once again, Spencer and Alan and Andrew, thanks for being our talking heads here in the future so I think I figured out how to keep an eye on the YouTube chat better. And now I just actually need to remember to make the damn link public a little bit further ahead. And, John Page, thank you for watching. And, well, hopefully we'll see everybody in the next T Tuesday updates. Thank you.