 The T2tile project is building an indefinitely scalable computational stack. Follow our progress here on T Tuesday updates. Hey, hi. Thanks for checking in. Stigma-gic state machines. It sounds like the same thing I talked about two episodes ago, but there it was state versus Stigma-gy. And here I want to talk, well, I mean, it's not like I set out to talk about it, but in the process of working through programming problems over the last two weeks, this is kind of what popped out. So when we get to the serious nerd stuff, this is what it's going to be. But first, right, in top stories. So the Living Computation Foundation, the nonprofit organization that we set up to take care of all this stuff. Then I mentioned last time that we have these exclusive LCF nerd numbers. You can join us and become a nerd for $5 or more on PayPal. And that I'm going to try over the next month to reach out to the nerds via email, using the email that people turned in for that. If you don't want your PayPal address, email address being used, you should send me a note, you know, actly at livingcomputation.org to what address you prefer and we'll update the records. But we have four new members, four new nerds. So thank you and welcome to Ian Fabian Spencer and Raphael. Spencer's been a long time contributor. And Ian and Fabian and Raphael are I don't know before, but some of them people included their mailing address, which is helpful. And so I can say we've got folks coming from Alaska to Germany and Switzerland. It's really pretty cool. And Spencer is another recurring monthly contributor, which is like way over the top. So thank you, folks. And I want to be in contact. And I want to talk back and forth as much as we can during the month of November when I am not going to be producing T Tuesday updates. After this one, the next one is going to be like December 6th or something like that. And in the month of November, just like last year, well, not just like last year. I'm going to try to do this nano-remo again, national novel writing month. I wrote 30, 40,000 words or something of which some of them were good last November. And I want to spend a chunk of time reorganizing that. I have some new ideas and some new approach and one key idea that I think as far as a sort of writer's technique that I'm going to give a shot. Well, it's just the idea that, you know, I was taught or I somehow learned that, you know, if it's true, if something happens, you shouldn't tell people about it. You should show it to them. And as I was writing last November, that's what I was really trying to do. There was a lot of stuff going on. So it took a lot of words. I mean, even when I started boiling it down to get through a particular scene because this happened and this happened and this happened. And then I came across some advice from Orson Scott Card, who was I was a fan of his science fiction when I read a lot of science fiction and he's, you know, he's done a lot of writers teaching writers, workshops or stuff and so on. And and he was pointing out, you know, sometimes you need to tell that the really and not show the really important stuff, the dramatic stuff you show. But otherwise you just exhaust the reader. And so it's OK to tell to get you to the next important thing. And I kind of needed that. So I want to go back and I want to do some telling. Just say, you know, weeks went by and they learned how to do whatever without actually explaining how they learned it, whatever. So that's what's coming on as far as the novel best effort science fiction novels set in the future. And in addition, this is the, you know, a crossover event between the Hyperspace Academy and the Living Computation Foundation to try to get out this second lecture. And I'll talk about that, well, right now, actually. So OK, living computation says, in the end, living systems and computational systems turn out to be the same class of systems. They may not look like that now, but that's because we've got some wrong ideas about what living systems and computational systems really are. And that constitutes the idea of this linkage between life and computation is one of these big picture ideas. And, you know, people talk about it all the time, you know, it's all just finance. It's all about money. It's all just physics. It's all just chemistry, biology, psychology, sociology, ecology, cosmology, you know, or it's all just duty, luck, God, religion, honor and so forth. And you can make a claim. But, you know, really, none of these things are actually true. You know, it's not everything is equally well explained by physics or money or honor, and it's not just that either. There's other stuff that gets in there. So all of these statements are it's all just X. It's all just computation are all overstatements. They're all strictly speaking, they're kind of lies. And we want to be OK with that. We want to understand that and recognize that whenever we say such a thing, we are vulnerable to people pointing out the cases in which it isn't. And we want to say, yeah, yeah, for sure. But I think we have a case in the modern era of understanding not just computation, but best effort computation to make the case that computation, understanding the relationship between computation and life can be a very clean, a very powerful way to rope in an awful lot of stuff that, you know, all of the all just X's, all of these theories of everything have to cover everything. So, you know, it's always going to be able to say, oh, yeah, well, finance talks about that as deficit inversions or, you know, whatever it is. And that's all fine. I think there's a few special properties that the computational case has and it leads us to be, you know, the sentence that scientists often find themselves or feel propelled to try to address the sentence. Humans are special because, you know, to answer that question. And this our approach, which is what we're going to try to work on to get the second lecture in the hyperspace academy introduction to classical hyperspace video over in the day of the channel in the month of November, it might not release in the month of November, but we want to get major production done, going for serious in November. Humans are special because where are we? There we are. We are coders. We are programmers. And the more I've sort of worked through this, I think it's got a lot going for it. And so that, you know, from the, there's this picture, we're all like these little programmable machines. We're all running around trying to program each other to do work for us, to get an advantage for us. And it all sounds extremely crass. And from one point of view, it is. But from another point of view, yeah. So there's still room for all of the other stuff as well. And there's sort of better explanations, I think, for some of it. So that's the goal. We are coders. And what are we coding? Yes, there are all these amazing digital computers, these octacore, blah, blah, blah phones and so forth. But that's not the main event. The main event is programming other people. As far as the sort of flexible, subtle machinery, capable of doing amazing things, people are the machines that we focus on coding for. And we are coders. Sometimes we're the machine. And that's as it has been. It's just the new era of computers, digital computers, manufactured computers, makes it easier to understand us by looking at that in relief. And so we're going to build a theory of living computation where we're going to build an implementation of what we're saying using the digital technology. And that's where the T2 tile, that's where best effort mobile fees all fits in as another description of the big picture, living computation. And, you know, I'm saying we could take a full lecture slot for this, so like 50 minutes or something. And we'll see, we'll see. I need your help. All right. And that's where it starts. We're coders. We're coders, we're coders. Sometimes we're the machine. All right. So that's that. And speaking of implementations, because it's all about the implementation, we left off last time that we were working on the source-routed streams, which are like, you know, TCP connections, where you can send a bunch of data arbitrary length, more or less arbitrary length from A to B. We had to invent a new addressing scheme because this is not IP addressing. This is not the Internet 126.123 BBBB sort of things. We did source-routed streams, talked about that last time. So there's been progress since then. So let's take a quick look at it and try to do a demo and then finish up. So this was source-routing. Go out the first port, pop your address off, and the receiving guy sticks on the port that it came in on. Go to the next place, take off the direction you went out on. Guy sticks on the address it came in on. So you end up building the route back in the process of going forward. We introduced these relative coordinates at the tile level. We already have relative coordinates at the individual sites, the atoms in the movable feast machine. This is another implementation detail using the same principle of spatial addressing. How do you talk to neighbors? Not by name, not by addresses given to you by the manufacturer. You talk to the neighbors by spatial address. Hey, West guy, how's it going? Hey, East and so on. I got the basic carrying data back and forth. This is one of the first times I got it going. I was just typing garbage and stuff to see that it would show up. So these are two command lines. They're both connected to this general purpose networking tool. They're talking to our source-routed thing. And hey, it went back and forth. When in one side came out the other side, and all of this stuff going on under the hood, and it was getting messy. It was getting pretty messy. I got it to work, but getting it to disconnect, getting the two ends to know that the other end had disconnected, it was nasty. And so by a week ago, Saturday, I was stressed enough about this that I was thinking about general ideas. I was thinking more and more about how one ought to represent state machines. Now, in traditional digital computing, when you have a state machine, you have a variable called the state variable, and it's usually just a number. And you associate state zero does this kind of stuff, reset, state one does whatever, and so on. And that's it. That's what it means to be a state machine. So then you may make transitions where you change the number based on input and stuff like that. That seemed more and more wrong. And in fact, that was what we talked about two times ago with state versus Stigmergy. But then I was thinking, you know, maybe they should really go together. And I came up with this idea that I'm currently calling Stigmergic state machines. And the idea is, and it's not a new, new idea. I mean, I've had the idea before in the CCR project back in the 90s. I did something very similar to this, but not quite in this context, and not quite as sort of as clean as this. And so the idea is when you ask for, you know, you often have a function, a method where you say, please return the state. And normally that would just get the value of that little state variable. But in our case, it's not going to do that. In our case, it's going to look out in the world and look at the data that would have justified being in state two and say, is the data there? Okay. Then it's at least state two. And then it's going to look out and say, well, could it be state three? Oh, no, it can't. So that's the Stigmergy part of it. Instead of having an internal variable, we're going to look out into the actual conditions of the world, the state of the stream and how many bytes have been received and whatever it is. The definition of the world can shift a little bit as we go. But the point is, it's all meaningful. All of the state that the thing looks at to decide, am I in the state or not, is not an arbitrary variable that was just put down to remember something. It's the stuff that generated it. So that's been working pretty nice. So, you know, all right. And then, you know, by the next day, I was thinking, well, it's like, you know, so we're in state need this a state where we have a need seem to be the right way to do it. We need configure unless we actually have a root array. We need to open, you know, that kind of thing. So that was the structure. This is not code. This was just me talking to myself that I was struggling towards this. And I couldn't, at first, you know, I couldn't clean it up. It all took a couple of days. And as usual, I had had a nice clean core in it, and then I rushed on and put a bunch of hacky stuff all around it that I didn't really understand and I couldn't sort out, couldn't debug. So clean slate, pull the pieces together where you just say, okay, give me a new empty screen and I'll just start writing again and then gradualize. Okay, well, this little bit is clean enough that I can bring it in and so forth. That's what happened. And eventually it kind of worked. And so here it was. The advanced function is the state transition function. And it says we should try to abort if we need to abort. If not, we should try to configure if we need to configure and so on. And we go through that every single time. It's not like we remember that we're past configuration and we can go on to contact. That's part of the robustness. If the world has changed so that whatever it was that called us configured was no longer true, we don't want to go on to the next one. This has been working out pretty well. I managed to get the life cycle of a stream. One guy connects. The other guy's waiting. They connect. They talk. One guy ends. The other guy ends. They try to get in touch with each other about ending. And it turns out that making a reliable stream of data in two directions over an unreliable network, which is what TCP does. The thing that's underlies HTTP, the worldwide web, everything, this video that we're watching right now. Probably, well, may or may not be transported by TCP anymore, but it was when it mattered. There's all kinds of subtle tricks and things don't actually guarantee to work as far as when they end. And there's always this infinite regress of, OK, he said I was done. He was done. I told him I was done. He acknowledged that I told him he was done. I acknowledged that I heard that it and so forth. And in fact, you have to go on and on and on and on and on. And you cut that off at some point. And then there's actually a vulnerability because that last one is not acknowledged. Whoever stops first is not acknowledged. And so the other guy is going to have to just deal with it. Give up and time out without any official justification of the infinite regress logic. And that's just something that's real that we live with in all of these things. All right. So, right, the definition of need configure is really just shorthand for, well, you haven't got a root. The definition for needing contact is you do have a root, but you don't have a sequence number, which means someone has talked to you and gotten started and so forth. Won't go through the details. But the long and short of it is I got far enough to say, okay, we can move files around, built a new script, SRF, source-routed files that can be a server to collect a file, can be a client to send a file. We'll try a demo. You'll see. And that got us back to the logging for the intertile events, which is what we've been trying to build infrastructure for for several months. So, progress. All right, let's try to do a demo. I've got the grid running here to turn the lights down, whoops. And actually, let me see if I can zoom in a little bit without messing this all up. Something easier to see here. My old display up. Oh, well, that looks might be possible to see something. It could probably go in a little further, but I don't want to mess with it. Okay, so the idea here is two of these tiles. Let me just, this tile here has got the yellow ethernet cable coming out of it because it's sticking out the bottom so it can do that. And here, this tile's got the white ethernet cable coming out of it, and we're going to try to send a file source-routed through the grid from the yellow ethernet tile to the white ethernet tile. And we've got screens here. Okay, so I've got this set up. I think it should work. So here it is, the program SRF, source-routed files. The first argument, ZOT, is just an arbitrary tag that the client and server both have to agree on in order to connect up. It's kind of like a port number in regular IP communications. And then here's the root. Got to sneeze here. All right, excuse me, I had to sneeze. The source-routed, how do we know? It's a server-routed because it begins with eight, which is us. So this is the white one, so this is the guy over here, and he's saying eight is on the server, and then the first stop is three. So zero is up, one is northeast, two is east, so three is southeast, and so we go southeast, east, east, east, east, southeast, and we should arrive at the other guy. And the other argument for SRF, when it's being a server, is a directory to put the files in, we say temp files, and there it is, now it's waiting. And whoops, and then we control seed it. I don't really know why we did that, but then, hey, wasn't it given that that would have worked twice? Whoops, I keep thinking these are Emacs buffers. All right, now here we are on the other side. We're running SRF again, same tag, but now we're having a client root because the eight is at the end, and instead we're going from out the seven, which is northwest, and then six, which is west, west, west, west, west, northwest to get in the reverse root. We're going to send a file that contains 25KB, here we go. Oh, actually, let's put up the CD, no, actually, wrong. I should, we'll just leave it. We'll leave the tile thing up here, the tile displays that we'll be able to see, that maybe we'll be able to see the bytes moving through the thing. We'll put the CDM display on the endpoints, like that. Okay, oh, and let's see, you can see that. That s10-2, that means there's a server running that is listening to 10 relative coordinates of 10-2 because we already did that. Down here, oops, on the client side, there's nothing yet because we haven't hit enter yet, but now we'll do that. Oh, now it's waiting to make contact. Oh, there it is. And, oops. Yeah, and I already, this is another feature. Since we put a big checksum for the whole file, a cryptographic checksum, in the initial file exchange message, the server knew we already had it. Well, we can fix that. Yeah, so we'll just take some more random data. All right, now we have a new 25KB file. And notice here that now we are starting the client side, although it's waiting for contacts. Oh, there it is. It's trying to connect to minus 10-2, and we don't have anything visible up here because we started the other guy. And that also didn't work in the middle of last week, and I can't do this again. All right, so we'll start up the server. And then things should start to move. Waiting for client. The client, there it is. So now 2.2KB, 8.7, and we can see the data moving through here. The big arrows moving right to left. Down through here. Now you must have seen it. I wasn't looking at it, but there's a lot of buffering in the net. So in fact, the 25KB was out of the client's hands long before the server reached it, received it, stashed it away, did the checksum, confirmed everything was okay. But it all worked out. Progress. All right, so that's it. The next update will be almost six weeks from now. December 6th will be exactly six weeks. I can't do arithmetic. Part of the reason that I'm doing this is when I tried to do nano-remo last time, I had a fence post error. Like I'm such a brilliant programmer, and I kind of shortchanged myself out of the actual amount of time I expected to have. So let's hope for the best for those of us in the United States and for everybody in the world who cares about what's happening in the United States. Let's hope for a soft landing as much as can be expected in the circumstances and be safe no matter where you are. And best effort. Hope to see you next time.