Programming Throwdown - 141: Social Gaming with Chip Morningstar

Episode Date: August 22, 2022

00:01:03 Introductions00:04:47 Mojovision00:06:07 Chips’ storied journey00:11:06 Project Xanadu00:18:45 Getting into Lucasfilm00:31:31 Artificial Intelligence in games00:39:48 GTA MP01:00:10 How the game industry drives people01:08:29 Agoric and its niche in the blockchain01:20:12 Javascript’s securability01:22:46 Working with Agoric01:32:20 What skills Agoric’s team looks for01:35:31 Chip’s parting thoughts01:37:00 FarewellsResources mentioned in this episode:Chip Morningstar:Twitter: https://twitter.com/epoptAgoric:Website: https://agoric.com/Careers: https://agoric.com/careers/Habitat Chronicles:Website: http://habitatchronicles.com/If you’ve enjoyed this episode, you can listen to more on Programming Throwdown’s website: https://www.programmingthrowdown.com/Reach out to us via email: [e-mail] can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Hey everybody! This is a super exciting episode. with Chip Morningstar. Take it away, Jason. Hey, everybody. This is a super exciting episode. I actually was just on my Oculus yesterday. So I'm a big fan of virtual reality, the metaverse, augmented reality. I love all of this stuff. And I'm really excited to talk about it and dive in on the technical part, on the product

part, and just explain everything VR. So thanks so much for coming on the show, Chip. I'm happy to be here. Cool. So just to get it going, what has been your favorite virtual reality experience? First of all, I should preface things by saying I'm a little bit of a virtual reality skeptic, in part because I'm terribly, terribly prone to motion sickness. And so you put me in one of those Oculus headsets, and I can last about two minutes before I'm just tearing the thing off and rolling on the floor in nausea, and damn, pretty much shot. So no, the thing that has really

impressed the hell out of me is tilt five i don't know what that is you have to explain it okay so tilt five was a creation of a woman named jerry ellsworth who discovered some phenomena when she was working on vr for valve and has now has since gone through the usual gauntlet of Silicon Valley venture capital adventures and things and come out the other end. What they do is rather than attempting to put you in a immersive experience, they have a set of glasses

that have video projectors on them. And they're literally small video projectors, which you then view through a retro reflective surface and which they then render in front of you as if you were looking at whatever 3d environment that you would actually be looking at in the physical world and it actually works it is effectively synced to physical world around you and it doesn't make me motion sick. So I love it. And I've been a big fan of Jerry's for years and years and years and years. And I totally recommend checking it out. Wow. Super cool. So what I was doing yesterday, which has become a routine for me is I actually put on, I have wrist weights. So they actually have a thumb

loophole and it has a Velcro strap. And so it goes around your wrist and adds weight there. And then I actually have the Oculus controllers, I have the wrist weights, and then I have the headset on, I do boxing. And so I've tried to add more and more like heavier and heavier weights on my wrists and then see if i can still beat this uh boxing game on hard and it's uh it's actually really really satisfying it's uh it's really fun getting punched in vr actually really bothers me it's getting to that point where like yeah like you just feel this visceral feeling when you get knocked out in VR, even though you haven't moved. Well, I mean, I think we're probably going to be seeing a lot of innovation in haptic interfaces of various kinds. Although the one that lets you get slugged in a boxing match may, you know, I can imagine there being a lot of issues with that.

Oh, yeah, I know. I don't think it's a good idea. Actually, the VR boxing has taught me, beyond just workout and cardio, it's also taught me that I really don't want to be in a fight. I don't think I've ever been in any kind of physical thing since I was, I don't know, seven years old or something. But it just reinforces that being in a street fight or something would be absolutely terrible. That's not a bad lesson to learn. I also have chess for the VR. And so there was a period of time where I was doing chess boxing, where I'd alternate from boxing, VR boxing to VR chess. I felt very...

That's a strange, I don't know if you want to call it a sport, but it's one of those things that I tell people about just to watch the look of disbelief. Yeah, again, I feel like I don't mind the chess part, but I really don't want to get punched in the face. So real life chess boxing is out, but VR chess boxing is actually quite fun. The other VR thing, which I think is really interesting, is Mojo Vision, which is a company founded by another longtime acquaintance. And their thing is a high resolution video display in a contact lens. Oh, wow. Along with various sensor technology to make sure it tracks your eye properly and your head movements properly and all of that. And once

again, it's more of an augmented reality thing where they can overlay the visual channel from the real world onto the visual channel from the display. And they've done some really interesting biophysical model of the human vision system stuff so that the resolution is adapted to your retina. And so you get a very high resolution thing. I haven't actually had the nerve to put a contact lens on my eye yet. So most of my knowledge of this is theoretical, but the people who played with it are very impressed. Super cool. Okay, so that's kind of a good lead in. So why don't we step back a little bit and why don't you tell us, Chip, about your kind of background, what you've been up to and what kind of led you to be where you are now at Agoric.

What's kind of your story? Yeah, I guess the question is how much biographical depth you care to go into there. What's interesting, I started out in aerospace engineering as a student, and I wanted to design spaceships and discovered, much to my disappointment, over the first year I had in school at the University of Michigan, that when you're an aerospace engineer, you don't get to design spaceships. You get to design like, you know, the third wing strut from the left. But in service of this sort of space vision, I managed through a combination of family connections and friends and audacity to get a summer job at the

University of Michigan Space Physics Research Laboratory, which was doing space stuff at U of M. And I was, you know, this is a sort of first part-time student job thing. I was basically a gopher. I worked for an electrical engineer who designed ground support equipment for satellite and balloon missions. And, you know, I did a lot of running drawings down to the drafting department to get updated. And because that was done in those days and, you know, filing product literature and keeping, literature and keeping basically gopher stuff. And they had ordered a PDP, a Digital Equipment Corporation PDP-1134 computer as a ground support equipment for a project called BOSS,

which is the Balloon Observation of Stratospheric Species, which was they would take a balloon package that they would take high, high up into the stratosphere, like 100,000 feet or more, and then drop it off of the balloon. And as it plunged down through the atmosphere, it had a series of pods that stuck out of it that couldn't look like jet engines that contained gas chromatographs. And what you'd get was essentially a core sample of the atmosphere at that point.

And then close to the ground, a parachute would pop out, hopefully, and then it would make a soft landing. And in support of this, they had this PDP-11, but the lead times for delivery of that kind of equipment could have been a couple of weeks or it could have been six or eight months because it was highly unpredictable. And so they ordered the computer months in advance of their actual need for it. And as fortune would have it, it arrived early. And so what they did is they plugged it in to make sure it worked. And they set it up in the back corner of an office, which happened to be

the back corner of the same office that they had me stashed in. And it was me and the PDP-11 for the summer with me without a lot to do, but there was a big stack of manuals. And I started playing around with it and reading the manuals and saying, oh, what does this thing do? And by the end of the summer, I was like, I'm having more fun playing with this thing. And I had taken sort of, you know, the first programming courses that they put everyone in engineering through as just sort of basic core skills, and had enjoyed that and decided, you know, I think I'd rather do this. And I changed my major to computer engineering. And that launched me into the world of software. Wow, that's wild.

So I think there's kind of a really good point there, which is you were kind of there physically with this computer and this stack of manuals. And that could look really overwhelming. A lot of people could look at that and say, well, how am I going to read through a stack of manuals? Or even people might say, well, this computer, if I break this, the next one could take eight months to arrive and they could be afraid for that reason. And so I think you kind of took the bold step to say, no, I'm going to learn this i'm going to uh uh you know take my chance with that and and it paid off yeah well also i mean i had a very supportive boss who was was just you know very happy to encourage me to explore and to fiddle with things and and

you know and and it's like no you you're not going to break the computer by typing commands on the keyboard and and we're used to things being complicated and technical and having a bunch of documentation you had to read that was, I think, more normal then than it is now. Today, we have, I think, more impatience, particularly with respect to getting started with something. One of the things, this actually dovetails with other stories about my career. At the University of Michigan, I fell in with a group at the Ann Arbor Computing Club, who included a bunch of the initial people at Project Xanadu. Xanadu was one of the sort of the original hypertext projects. In fact, it was founded by Ted Nelson, who is the person who actually coined the term hypertext. And they had this whole vision for this worldwide,

this thing that looked very much like the World Wide Web, except that I think their vision, it worked better than the World Wide Web actually works. Well, I mean, that's the thing is in your imagination, things always work better than they do in reality. who was a researcher at SRI who had done a system called Augment that was one of the very first hypertech systems. And there's a very famous demo that he gave, I think it was an ARPA conference or something. There's a video of it you can find on YouTube,

which is referred to by a lot of people in the industry as sort of the mother of all demos. It's one of these sort of seminal events that kicked off a lot of stuff, kind of opening people's eyes as to the possibilities. And one of Doug's theses was that what you wanted to do was augment people's capabilities with computers. And he didn't mind if you had a little bit of a learning curve at the beginning because you'd have an investment in learning how to use this tool, there where you might have to take, you know, a few weeks to actually master something as opposed to expecting that you should be able to just sit down and

immediately jump in and start using it. Because you spend a few weeks learning something, but then you're going to use this tool for the rest of your life. And so, you know, paying the upfront learning cost was fine. And nowadays, we're much more impatient, we're much more expecting sort of immediate gratification at the starting point, even though in fact, experience has taught us that it really does take weeks or years even for people to really acquire mastery of a lot of these tools. We look at something like Adobe Photoshop or any of these 3D modeling and editing programs, and they really do take months and months and years and years to become truly skilled at them. Yeah, that makes sense.

So a couple of background pieces there. So SRI is, and correct me if I'm wrong, Stanford Research Institute, right? It was the Stanford Research Institute, and they rebranded it as SRI when they got spun off from Stanford as part of the divestiture from universities of a lot of research institutions that had ties to the Department of Defense back in the late 60s, early 70s. Oh, I didn't know that. Interesting. I worked at a lab back when I was a student called the Environmental Research Institute of Michigan, ERIM. And that was also a spinoff from the University of Michigan. It used to be the Willow Run Laboratories of the University of Michigan. And it got spun off back in the early

70s as a result of anti-war protests, because a lot of their funding came from the Department of Defense as well. And that was the moral panic at the time. I think a number of institutions that kind of went through that transition. Got it. So you changed your major to computer engineering and you went through and got that. And then what was your first job out of college, your first computer engineering job? Yeah, it depends on how much details you want to go into. Once again, my first job was this job at the Space Physics Lab where I sort of gradually, you know, took on more responsibility and, you know, did more actual hands-on technical things as I said, a lot of the engineering we were working on was ground support equipment for support of various spaceflight projects. And there's a lot of hardware prototyping. And in some cases, not even prototyping, we're just actually building hardware, and it wasn't necessarily spaceflight hardware, it was ground support equipment in support of spaceflight hardware. And so a lot

of it was done with wire app prototyping boards. And there was a utility called wire app that ran on the University of Michigan time sharing system, where you would specify you basically you transcribe your circuit schematic into a macro language that said you're using the following gates and chips and other things. There were macros that encoded the geometry of the chips, which pins were connected to which inputs and which outputs. And then you would specify the logical connectivity of this device in this textual macro language.

And then you run it through the wire app program and it would spit out variously diagrams of the wire app board that would result, plus instructions for a technician to wire up the board and where to plug the chips in and what pins to connect to what other pins, or actually produce a tape or a card deck to drive an automated wire wrapping machine to actually assemble or fabricate the device that you had in mind. And I became the person responsible for maintaining this. And they had a bunch of fairly complicated additions to this program that they needed as the geometry of the prototyping boards that they were having got more flexible and more sophisticated. And I took over maintenance of this thing, which was this enormous piece of IBM 370 assembly language software. But unfortunately, it was really well written, really well structured IBM 370 assembly language software. And I learned a lot from studying this code and then ended up augmenting it at length.

And I got contacted by this other entity I mentioned, the ERIM, the Environmental Research Institute of Michigan, who were also doing prototyping of hardware using the WireApp program, and they had some even more sophisticated things that they wanted to do to it. They said, well, why don't you come work for us? We can pay you much more, which was, you know, I was essentially earning minimum wage at the Space Physics Lab. Mind you, I'm like at this point, I'm like a software junior in college. And, you know, they offered to like double my income from like, you know, $1.80 an hour to $3.60 an hour or something like that, which to me at the time, what was early versions of what we now call LiDAR.

We called it the Flying Spot Scanning Laser Sensor or something like that. Essentially, it was raster scanning a laser range finder. You get these images, which were depth images rather than optical reflectance images. And then we had a thing called the CytoComputer, which was a massively pipelined parallel image processing machine that had been developed at ERIM that I learned to program and then ended up actually developing a programming language for doing image processing.

So, yeah, how did you get from there to lucasfilm then ah well so what happened was iram would send you to like one major conference a year as an engineer and i went to the national computer conference in anaheim in 1980, 81, 82. I guess it was probably 1981. I don't know. I don't remember the year. It doesn't matter. So one of my best friends, actually the best man at my wedding,

had gone to work for Atari. And Atari had a sort of joint venture project with Lucasfilm to do games. And as I was getting ready to fly out to NCC, I was talking to my friend Tom on the phone, and he said, well, I'm going to fly into San Francisco and go visit Lucasfilm. And at the time, my family lived in the High Sierra in Nevada, California. My family's business was a small lakeside mountain resort up in the High Sierras. Also very influential on my, let's say, moral and intellectual development.

But be that as it may, I thought, well, actually, I could change my flight plans to fly into San Francisco. And I can tag along with Tom while we visit Lucasfilm. And then we can go up, visit my family, and then drive down to Anaheim, which is what we ended up doing. And so I did that and just kind of tagged along. And I got to see the Lucasfilm offices and get to meet with some of the people there as we were doing it. I mean, we were just basically being, you know, technology tourists. But it was really, really nice. I mean, they had vaxes.

They had faxes? Vaxes. The vax. Oh, fax. Oh, yeah. The computer of that era. Right, right. You could just go down to the store and buy one, you know, because it costs, you it costs 20 times what your annual salary would be.

And they had these high-resolution graphics displays, and they were doing this really cool stuff. And I just kind of went away from that saying, wow, that would be a cool place to work. This is a bit of a segue, but I just wanted to interject here for a moment. I asked somebody why – so I'm kind of not that good with hardware technology. I do have an Oculus, but to be fair, I got it for free because of some work I was doing. So I don't think I would have had one otherwise. And I'm just not like a person who has like, you know, big monitors or anything like that. But my desk had these two large monitors and they were never really on.

You know, at one point I kind of asked why, you know, even there were desks that nobody was sitting in that had these huge monitors. And I asked them, why does the facilities folks just put huge monitors on all the tasks? And what somebody told me, which is really interesting, they said, because when candidates come to interview here and they see all these huge, expensive monitors, they feel like, oh, these people have cool equipment and it must be a really cool place to work. And I had not thought of it that way at all until when someone, it's almost like seeing Mickey Mouse without their mask on or something.

Like the mask comes off and you're like, oh my gosh, this is really what it's about. But I think there's a lot of truth to that, I think. Well, I mean, certainly that, I mean, sort of pure technology lust. The Lucasfilm offices definitely inspired that, although there was also, you know, the carpet and the woodwork and the brass and the, you know, original Star Wars pre-production artwork hanging on the walls and a lot of other things that, that other companies offices don't have. Nice. I heard that Atari offices were wild. Like I've heard all sorts of stories. I don't know which ones are true, so I don't want to say any of them, but I've heard.

Well, certainly at, at well, when I, when I actually ended up going to work for, for Lucasfilm, what happened was the Sraph conference in i guess it would have been the summer of 1983 was in detroit so i guess it was 82 when i when i visited them um and bill reeves who was one of the graphics guys at lucasfilm had done this paper on particle systems. And it was sort of the seminal particle systems paper. And I was just overwhelmed at how cool this was because it was the first thing I'd seen in computer graphics.

It wasn't just about drawing polygons. It was about making images. And I thought, wow, these, these, these guys have really got it dialed in there. They're on onto something significant here. And so just on a flyer, I sent them my resume because their address was in the colophon of the SIGGRAPH paper. And I just sent them my resume.

And it's kind of like entering the lottery where you pay two bucks for your lottery ticket and you get to dream about what would happen if you won $100 million. And in this case, it was 25 cents for postage and you get to dream about, well, what would it be like if you got to work for this cool company doing this cool stuff?

And then in the fall, Xanadu, which I mentioned previously, had actually gotten some funding, part of which was to move them from Ann Arbor to the West Coast, where they'd be closer to where the action was. We were getting ready to pack up our house and we're literally like a half hour from having the guy from AT&T come and disconnect our phone which was also a thing back in those days when my phone rang and it was Peter Langston from Lucasfilm and he said is this Chip Morningstar and I said well yes it is and and he said well this is this is Peter Likes it from Lucasfilm. And I was like, whoa, why are you calling me? What had happened was they had gotten

my resume and somebody had looked at it and said, maybe this is somebody we want to talk to. I don't know. But then he had lost it. And he was going to get in trouble with HR because he'd lost his resume. And so he said, could you send

me another one? And I said, I'd be happy to, but I'm still moving. He said, well, give us a call when you get in. And of course, after that, they had to have me up for an interview. And so I say, the way you would get hired at Lucasfilm was to have a memorable name so that they could find you in directory assistance and then have them lose your paperwork. There is this, there was this time where we thought we would randomly shred half of the resumes so that all the people we hire are lucky. That's yes.

So maybe you were one of the lucky ones. Yeah. I don't want to hire unlucky people. Maybe they quote unquote lost the resume. That's actually a plot thread in, I think, some of Larry Niven's known space stories where he posits that in the future to limit population growth, they have the right to have children be the result of a lottery. And now, generations, they have selected for a population of people with genetically endowed luck. That's awesome.

So you joined Lucasfilm through the resume. And then were you sort of assigned to work on... Actually, before we even talk about that, so why don't you talk about what was Habitat or what is Habitat? Well, Habitat was a project... Well, actually, it does tie in a little bit to what was Lucasfilm about,

which is I ended up hiring on with Lucasfilm Games, which was not the graphics group doing the cool computer graphics. They were eventually spun off into another company, which we now know as Pixar. And they've come full circle and been reacquired, which is kind of cool. Yeah, they're both owned by Disney now, right? They're both owned by Disney now.

When Lucasfilm had all of these really innovative sort of research groups doing advanced technical things for technology related to film and entertainment, and one of them was the computer graphics group. They had a digital audio group that some of them did the first audio signal processing work. And they had a games group, which was basically started because Atari gave them a chunk of money to do that. But then when they went through some corporate evolution, decided that they needed to spin these businesses off because it was too expensive and distracting,

they kept the games group because it was actually producing entertainment products as opposed to technology. But our charter from George was, and I remember this very vividly because we had this amazing meeting. He said, your mission is to stay small, be the best, and don't lose any money. And so we had sort of pretty much free reign to do whatever the hell we wanted as long as somebody else paid for it. And that turned out not to be too hard because lots of people wanted to get close to the reflected glory of Star Wars and would come bring us money to do things.

And one year we were approached by a guy named Clive Smith, who was the VP of strategic planning for Commodore International. And they had undertaken a couple of strategic initiatives that year. One was the acquisition of of amiga and the other was a big investment in um so every year they would they would come out with a new guga to go with your commodore 64 and for the christmas season and this year it was going to be a really cheap 1200 baud modem and uh and as part that, they had made a strategic investment in a company called QuantumLink, which was an online service devoted to Commodore 64 users. And it was one of the first,

I think the first really consumer oriented things like that, where there were these online services that charged by the hour to use them, and they're quite expensive. Coffee serve would be $8 to $20 an hour. And in that environment, they were offering a service which was $3 an hour. And part of that was because they were only open evenings and weekends, purchasing unused network capacity from commercial X25 networks who mostly dealt with business customers. And then they did some really innovative things with, because it was all for the client, for the Commodore 64, they could do a custom client that optimized their use of the bandwidth and did all kinds of zippy interactive stuff and delivered a much more approachable sort of

consumer-oriented service and they were interested in games that would use this online service and of course Lucasfilm hey you know let's let's get them in it and and so they came to us and said what can you do for us and at the time when anybody in the games group had an idea, what they would do is they'd write up a two or three page sort of summary of their idea. And then, you know, it would get circulated around the group and discussed and ultimately find its way into a folder in our general manager's file cabinet. Steve Arnold, who ran things, would just keep this inventory of potential projects. And then when somebody would come shopping, he'd kind of gauge what they were interested in and pull some of these things out of his file cabinet and say, hey, well, we've got these things. And I had cooked up an idea for something along with my then office mate, Noah Falstein, for something we called Lucasfilms Universe, where we had started arguing about artificial intelligence for games. Wait, Noah, is Noah Falstein the secret of Monkey Island, I think?

No, that's Ron Gilbert. Oh. No, I think involved in Monkey Island. All of us were involved in all of these projects. But Monkey Island was mostly Ron's doing. I can tell you some stories. But anyway, one of the things that we were having this argument over lunch and I said, well, I don't know how to create an AI which is as rich and

as subtle as an actual human being in terms of the interactivity that it can give you. But why don't we just connect you to another actual human being? And that spawned this kind of vague proposal for this multiplayer open universe thing that probably from its initial description looked a lot more like spacing on the name the space game that's run by the company in iceland oh uh eve online eve online yeah it's it the description looked a lot more like that but when quantum link came came to us and said what can you do we pulled this this proposal out of out of the drawer, and they got very, very excited. And one thing led to another, and then we had six or eight months of lawyers negotiating with each other because that's how these things work.

But it was pretty clear it was going to happen, so I spent six or eight months doing design ahead while we were waiting for the lawyers to finalize the paperwork so I could actually start working on the project or like hiring people to do the work and stuff. And it evolved into a design for something that it went through a bunch of name changes along the way because of mostly because of trademark issues. And the name that we ended up settling on was something called Habitat, which in retrospect, I mean, it's a really dumb name for what it was, but names are like that. And Habitat was really the first, what we now call massively multiplayer online games. It was a bunch of, it wasn't just two or four or eight people in some well-defined game.

It was an open-ended, open-world thing that allowed, you know, these graphical figures that I called avatars to, you know, see each other, to move around, to talk, to interact. It was as much a social space as it was a game. It didn't have a lot of the explicit game goals that you get with something like World of Warcraft. It was much more like, I guess the closest modern analog would be something like Second Life, except that it was all on Commodore 64s and ran over 300 and 1200 baud modems over commercial packet switching networks. So was this like a text-based or what was the user interface? You can find screenshots of it. And in fact, as a result of a project that we did over the past few years, the Museum

of Arts and Digital Entertainment, which is a video game museum in Oakland, California, sponsored a project called Neo Habitat, where we took the original Habitat client software running in a web browser in a Commodore 64 emulator, backhauled over the internet using emulated Commodore modem to a server that we reconstructed from the original Habitat source code. And you can go to neohabitat.org and you can actually play this game in all of its 8-bit glory

and 1200 baud bandwidth experience using the Commodore floppy disk drive, which is the world's slowest storage device. We were doing what essentially amounted to object-oriented virtual memory using a floppy disk drive. It's a graphical world and you can walk around and you can interact with other people

and you can talk with them and do various other things. And it spawned a whole subculture of people who really, really got into playing this. And I've written extensively about this. Got it. So maybe this was in part like inspiration who really really got into playing this and i've written extensively about this got it so this so maybe this was like uh in part like inspiration for second life and world of warcraft and and all of these things that came afterwards randy farmer who was the main programmer i hired to work on

this who eventually became a full partner in the whole enterprise and uh and i have uh to say written extensively about this talked about it a lot and it and it has had a lot of a lot of influence and we actually got the first i guess they call it now call it the uh pioneer award but at the time it's called the first penguin award from the igda which is that the game developers version of the academy of motion picture arts and sciences is sort of the the oscar of the computer games world for having kicked off the the mmo genre so just to recap a little bit so so the virtual reality stuff kind of makes makes you ill from from the motion sickness all of. So that's not necessarily your cup of tea. Your cup of tea is really the, like a lot of these sort of like social,

you know, multiplayer. One of the things that kind of discovered is in the course of doing this was that it's very easy as technologists to get very absorbed in the technology. And it is really interesting, but a lot of these systems have had the property of being, you know, sort of more interesting you know, $80,000 computers, early versions of head-mounted displays and various other things, interface devices,

like there's a thing called the data glove, which was an instrumented glove that would capture your hand movements and other things. And there were lots of people who were thinking, oh, this is going to be so cool once it works. And so there was a conference called the First International Conference on Cyberspace that we heard about. Somebody said, you know, oh, you guys should talk at this conference.

And we learned about this like the day before the deadline for submission of abstract. And so we frantically threw together this really audacious abstract without having any real idea what it was we were going to say and faxed it off to them in a hurry. And then the paper ended up getting accepted. So we ended up writing this thing. And we go to this conference and there's all of these people talking about the things they'd done with their $80,000 Silicon Graphics workstations. And we had this thing where we were doing this thing with this $150 computer even $150 at Kmart. It was $10 at a garage sale because at that point, even the Commodore was basically well into obsolescence. And we talked about what we had done and what we had done was a lot more interesting in some ways than what the people with the big expensive hardware were doing. And part of it was what was forced on us by necessity.

All the interesting stuff had to do with the interactions between the people online and the things that we discovered about things like community management and the interactions among a big user population and the kinds of emergent social structures and emergent behaviors that you got from that. And from our perspective was actually a lot more interesting and probably a lot more important than the actual underlying technology.

That makes sense. There was a project that really fascinated me called GTA MP. And the idea was they took GTA Grand Theft Auto 3, which was not multiplayer, or maybe it was, but just with a handful of people, or maybe not even multiplayer at all. And they somehow, I don't know if this was developers who quit and like, I don't understand tech from a technology perspective, how this was possible, but they were somehow able to take this game and make it massively multiplayer without having access to the source code i don't really know what what happened there that's yeah i don't i'm not familiar with that i mean there is there is a long tradition

of what is actually a terrible terrible engineering pattern of taking a what was otherwise a single user game and sort of sawing it in half and then stretching the two halves over the network. And usually the result of this is very unsatisfactory because it doesn't take into account all of the weirdnesses that happen when you actually have a network, including strange time lags and all of the sort of distributed data consistency issues and all of this kind of stuff. That is what makes these things technically challenging. So, yeah, I agree with you. I mean, from a tech standpoint, there's like all this warping, time warping and all sorts of weird behavior. But the thing that was interesting was, you know, when you started this thing, there's I think up to 200 people on one game on server and so when you started this thing it was exactly what you would expect when there's no consequences for dying like basically like i remember i joined the server and i got like someone kamikaze to 747 into me and i

just died and i woke up at the hospital and then uh in the game and then like you know another 747 crashed into me and it was just chaos but then and so i thought well yeah this is kind of what i would expect when you could just teleport anywhere and and and there's there's just total chaos but then like out of that sort of primordial chaos grew these servers where people had rules that, you know, there were administrators, and administrators forced, you know, rules and economics and scarcity and all these things. And then out of those rules came actually really interesting social hierarchies and social structures and all of that and um i just that seemed like that was just that blew my mind the fact that that all of that kind of emerged from this one sort of hack that all of that social

structure is built up on top of that that kind of evolution is is not an uncommon pattern one of the things that happened with with countertat is we had controversy because there are different different sort of styles of play. And there are some people who are into it more as an explicitly game kind of thing. And there are others who were just using it as a social space. And so we had put in weapons because, you know, it's a time-honored video game thing. And there are some people who are very, very upset by that and didn't like any kind of even performatively violent stuff going on at all.

And so what we did is we had different parts of the world. So in town was what was a weapons free zone. I mean, you could carry them, but they wouldn't work. And then sort of out in the hinterlands was sort of the Wild West and anything goes. And so the people who were interested in doing just purely social stuff would hang out in town where all the other people were. And the people who were wanting to do combat and that kind of thing would go out in the woods and shoot it out we had the major form of avatar customization that you could do given the limitations of the graphics technology at the time was substituting your your avatar's head and there was a palette of 256 different heads that we had provided that you could

swap in and out but it wasn't just that you got to pick one of these 256 heads you had to get a head from somewhere um so you'd go to the head shop and there would be a vending machine that sold heads and some were more scarce than others and so if you want to swap your head you have to take your head off and put it on the ground and then pick up a different head and put it on and people discovered you just take some something and put it on the ground somebody else could pick it up and run away with it and so the question is how do you execute a trade it's like i'll swap you this thing for for that really cool head you have yeah you need to set up like escrow services now well indeed in in in some later systems we we did exactly that but but i think world of warcraft has an escrow service yeah they have

a little third panel. So I'll give a bit of background for people who have never bought a house. The way it works when you buy a house is very similar to the way you trade items in World of Warcraft, where you give the money to a third party person who both you and the seller trust. The seller gives the deed to that person. And so there's a moment in time where you don't have the money and that person doesn't have their house.

This third party person has both of those things, but you both have to trust that person not to steal from both of you, right? And that's why usually some big institution and then that escrow service then gives each person the item from the other person and world of warcraft had something similar where you know if i wanted to trade a sword for a shield it's been forever since i played this but but uh you

know i would drag my sword into this thing they would drag their shield there's also a delay so like they couldn't drag their shield out right before I clicked accept or anything like that. There is this anytime someone edited anything in the escrow, it grayed out all the buttons. Well, you need an interlock where both parties have committed to the same state of things before actually execute the transfer of ownership. Yeah. We actually did in a later later system not in habitat we actually one of the first things we did was implement what we call the trading machine which which essentially followed exactly the pattern you described there largely as a result of this experience with people stealing stuff from

each other when they could inhabit well one of the things that happened is we didn't have any means technologically at that point to to that. But people were nevertheless upset. We said, well, what do you want to do? And people, the users said, well, we want to have a sheriff. And so we whipped together some code to create a voting machine, which we could do relatively easily. And the users themselves organized a thing where they had a couple of people who put themselves forward as candidates for sheriff. And they had a big candidates debate

where people came and asked them questions and they answered the questions. And then they held an election. And then this one person was elected sheriff and we gave him a special avatar head that had a big 10 gallon hat with a star on top of it. And he was the sheriff. And literally all he had was this special hat, but also he had some moral authority. I was assuming that the sheriff could just insta-kill people or something. No, actually all he had was a hat.

But like I said, he had moral authority. And what was surprising was it was remarkably effective, given that he had no actual authority to actually do anything. He merely carried with him the support from the community. And that turned out to be sufficient you know given that the user population was was really huge for that day but small by current standards like 15 000 people or something you know he could go talk to folks and say hey that was really not cool you should give that back and um well 1500 people but that's that's probably there's probably no sharding right like world of warcraft has so many people but it'sarded, so you really only see a handful. Yeah, well, we have a completely different way to distribute the load and how it all got handled in terms of scaling. And in fact, the architecture from Habitat has propagated forward into the future.

And we've gone and implemented several different generations of servers over the course of various Silicon Valley adventures with different companies, ultimately culminating in something that I managed to get pride loose when we did a version of this at Yahoo and got released as open source. And so I have a server platform called Elko that is linked from my blog and it's got, you know, you can get all the source for it. It's on GitHub and you can just use this. And this thing scales like crazy for a given the kind of scaling model that we had. And our model was instead of having different pieces of you know having basically different shards of the world instead what happens is each each little piece of the world is a is a separate is a separate place and then you just you you load the parts of the world that people are actually using into the into the server and then when you go from one

place to another you essentially have a handoff from one server to another. Today's sponsor is Mergify. Mergify is a tool for GitHub that prioritizes, queues, automatically merges, comments, rebases, updates, labels, backports, closes, and assigns your pull requests. Mergify features allow you to automate what you would normally do manually. You can secure your code using a merge queue,

automatically merge it, and many more features. By saving time, you and your team can focus on projects that matter. Mergeify can coordinate with any CI and is fully integrated into GitHub. They have a startup program that could give your company a 12-month credit to leverage Mergify. That's up to $21,000 of value. Start saving time. Visit Mergify.com to sign up for a demo and get started.

Or just follow the link in the show notes. Back to the episode. Yes, I mean, this is similar to how the cell phone network works. Like when you're on the highway, you know, your phone is getting handed off from one cell tower to the other, and there's a bit of overlap. But well, it was interesting is we have a very different scaling strategy from the web, and it's often hard to explain to web people. It's funny because I've had conversations with web people and games people, and last time I was actually deeply engaged with this server technology was about 10 years ago.

We had a company that was doing some, in this case, we were using the same server backend, but we were doing mobile games, geo-based mobile games. And I was saying, well, you know, we can handle about 250,000 concurrent users per server. And you say that number to web guys and they're like, no, no, that's not possible. And you say that to games guys and they're like, no, no, that's not possible. And you say that to games people and they say, yes, sure, so what?

It's just a different perspective. And it's because the architecture is oriented to fundamentally different kinds of operations and use of the network. I think the HTTP in particular is a very inefficient protocol. My sort of cynical way of putting it is like the most expensive thing you can do with a TCP IP network is open a new connection. That's like the highest overhead thing that you can do. And so I think that the philosophy of HTTP is, well, it's this expensive operation. So if you do it a lot, we must be providing you a lot of value. And web servers will try very, very hard. The thing that they really are deep down in their hearts jonesing

to do is to close the connection because they think an open TCP connection is like super expensive. It's a super expensive resource. And the answer is no, it's not actually a super expensive resource. It's actually a very cheap resource. What's super expensive is having like an entire process devoted to that connection. I wonder if there's a connection between or if there's a semantic connection between the fact that HTTP is such an ephemeral thing. It wants to open the connection, do something really quick, like send you a JPEG or something, and then kill the connection. I wonder if there's a causal link between that and the short attention spans we talked about earlier. That's an interesting take, because a lot of the stuff that we've done has been based on

long-lived persistent connections. And having a single server that just had a couple hundred thousand open TCP connections to different clients, it turns out a modern computer can handle that just fine. Now, that computer is only running half a dozen processes to manage all of that stuff, which is why we can sustain it. But there's a whole set of dogma about statelessness that figures very heavily into the scaling story that the web employs. And you get a lot of leverage from that. And for the kinds of things that the web does, this notion that you can horizontally replicate web servers that are completely decoupled from each other and basically scale arbitrarily wide because you have this stateless protocol is actually very powerful. And it's something that they've leveraged tremendously. What that story leaves out is that, in fact, actual real user applications that human beings use have state associated with them.

And typically the way that state gets maintained because everything is short-lived is in a database. And so what ends up happening is you end up using the SQL database, typically as your short-term memory bus, which is, once again, a really super expensive way to do that. Yep. Or you'll use like Redis or Dynamo or whatever. Yeah, there's a whole bunch of different tricks that they've taken to take this fundamentally inefficient thing and make it go fast. Whereas our approach was to say, no, all of this stuff is just state that's in memory. And then what you do is instead of moving the state around by passing it through a database, you move the users around by controlling which server and which process they're connected to. It's almost like a user is like a sort of like a Docker container or something that could be like containerized. That's actually a reasonably good, good model.

And I've written up this sort of scaling story once again on, on Habitat Chronicles and, and you can read all about it. And it's not even a particularly exotic thing. It's just a different philosophy for how you spread the load out. And rather than spreading out the individual HTTP request, you spread out the different interaction contexts. And one of the things that this allows you to do, which is really cutting against the grain for the web, is the model of the web is very, I guess you say it's very autistic. You talk to the server and the server talks back to you and that's it. Whereas in our system, you send a message to the server, which can result in

a message going to some different user, or the server has some autonomous process that's going on and it at some point decides it wants to send a message to you. And it's not that you can't do these things in the web. I mean, people have done these things in the web and they do them all the time, but it is kind of cutting against the grain of how it works fundamentally and whereas we just sort of embrace that more more directly yeah that makes sense you know i think the i think a lot of people um you know get into computer science through games right right? I think that they play games and then they see these amazing virtual worlds. They see the fact that,

and maybe this isn't true anymore, but at least when I was playing games for Atari and for Commodore, you'd see a handful of names on the creators of the game. And I would always think like wow these three people made this thing that that uh is creating like hundreds of hours of entertainment just for me so so it's like imagine if you scale this out it's like three people let's say those people

worked for six months so in one one and a half people years of effort, you know, they created millions of people years of entertainment. And I always thought that was really amazing. And I think that resonates with a lot of folks. But then, you know, you contrast that with all the sort of horror stories of working in the games industry. And so that's actually what drove me to not be interested in working on games. But I was wondering what your take was on all of that. Well, it's interesting because my younger son, a few years ago, graduated from University of California, Santa Cruz with a degree in computer science game design.

Because he had exactly that sense of it's so cool, you know, being able to just create stuff. And what was interesting was the games program at Santa Cruz, which is quite good. in the traditional computer science program where they dispense with some of the more esoteric, more mathematical stuff with more emphasis on things like project management and team dynamics and a lot of that stuff. Here you have a group of people who are trying to get something done collectively. How do you coordinate them? How do you deal with the intra-team social dynamics and all of that kind of stuff? And ended up deciding for exactly the reasons you just cited, that he did not want to work in the games industry because it was very abusive to its developers in a lot of companies. I mean, there are a lot of great companies that aren't like that, but there is this,

there is this sort of tropism towards driving people too hard. But it turns out that his, his, his training, which had emphasized a lot of this more sort of practical sort of social components of the software development process was a great background for doing all kinds of software engineering stuff. And he's now working at Google and is very happy there. And the training he got in games development turns out to be a much better match to the real world of software engineering than a lot of computer science programs actually give you, simply because of this emphasis on the project management

and team dynamics side of things. Well, okay, so there's some, I mean, Google is a good example. So at Google, you know, there are projects, there aren't extremely strict, well, there's people working on hardware, but for the most most part there isn't a very strict deadline so it's like we have you know we have a new version of youtube and if it's two weeks late it's you know it's not the end of the world and so people march forward in that way is is that what makes the games industry kind of notorious for driving people? Is it the fact that like this game has to come out on this day? Or what is it about the games industry? Well, I'm not sure. I mean, I've kind of been out of the games industry for a while. So I'm

probably not the best person to comment on the current state of how things work. But certainly, and I think to some extent, this is still true, there was a fairly tight coupling to the Christmas shopping season. And so one of the major peaks in sales volume was people buying games for friends and family as Christmas gifts. And so there is enormous premium on making sure that your title was in the store in time for the Christmas shopping season.

And obviously the distribution channels have changed enormously now. For example, games are almost entirely distributed online, whereas in the earlier generation, you actually had a retail package that had to be put in a box and shipped to stores, which increased the lead time. So the way we used to say to Lucasfilm is that Christmas is in August. make the ship date for this year's Christmas shopping season, it meant that you either released after Christmas, in which case you missed all of the sales and your return was much, much lower, or you were delayed a year, which had capital cost. And given the rapid evolution of the technology, it meant that you had a game that was a year behind the curve in terms of the technology that people expected. And so I think that seasonal component is not as pronounced as it once was,

but I think it's still there. And there's also, once you have started to spin up the sales and marketing machine to start promoting something, you're investing a lot of money in, if nothing else, all of the sales and marketing people that you've got working on it. And at that point, you're talking about making a pretty large expenditure in advance of when you can expect to see any revenue come back. So if you spin up a big sales and marketing organization, and then the product is delayed two months. Well, you're paying all of those people's salary to be sitting around for two months without a product to sell. That's very

expensive. And that dynamic is across the software industry. I think it's probably a dynamic that applies to many, many industries, but it's worse in software because of our terrible ability to do scheduling and planning. This is a question which has obsessed me since almost the start of my career, which is why is it so hard to plan and schedule software development? And my hypothesis is that because it's designed all the way down. Yeah, I was actually just about to say the same thing. Yeah, to take another industry

that I have some exposure to, which is feature film production. I used to work for Lucasfilm. Even though Hollywood is notorious for some quite famous budget blowouts and schedule overruns. For the most part, they're actually quite good at scheduling and managing costs. And part of this is because once you have a shooting script, you can plan out the filming and post-production process pretty reliably from that because you have this plan that you're working from. And when you're spending $200 million to make your

feature film, the cost of the script is, even if you've got a very highly paid screenwriter writing your script, the cost of the script is kind of a round-off error in terms of the overall cost of the production. And so if it took two weeks to write the script or if it took two years, it kind of doesn't matter because that all happened at the beginning when you weren't spending very much money. Whereas when you're doing software, by the time you have a description of the product that is sufficiently detailed, that you could actually say, how long is that going to take?

Well, that is the product. You are done. It is 100% the design process. And everything short of the finished product is an approximation where there's a bunch of stuff in it that you don't understand yet because you haven't delved into them well enough to know what you're going to be doing. And why I like to say this is we in the software business don't know what we're doing. And I don't mean that in the sense of being incompetent, although that is sometimes a problem, but just in the sense of you only find

out in the doing of something what is involved. And I kind of come towards a philosophy of this, that software is not so much a design process as it is a discovery process, that you are in the course of doing it, you are learning what it is that you're doing you are figuring it out as you go along and that is kind of a necessary irreducible aspect of of the process and people would like to pretend that it's not so but they're wrong yeah i mean i i think a good analogy is if you look at some of these like massive works of art like the sistine chapel or something like it's it's it's the the roof of that is all one giant mural that is all kind of flowing and if you decide to like you can't decide to sort of change the color scheme or something like that like you've you've committed to that and if you do decide to make

even you know subtle changes that you can make it's going to be extremely time consuming because it's this sort of web like this thematic web and um um you know if you change one end of it you actually have to change the the whole thing um and so yeah i feel like i feel like it's a it's kind of an art process like that that has to be sort of thematically and like stylistically sort of consistent and uh yeah that makes a lot sense so is there a is there like a contemporary game you know that that gives you sort of those habitat you know you could have played it or you could have read about it but it gives you sort of those habitat kind of vibes like we talked about it, but it gives you sort of those Habitat kind of vibes. Like we talked about EVE Online.

Are there other sort of social games where you can say that? I would say the closest modern parallel to Habitat is Second Life. Now, Second Life is, I'm not sure what state they're in at the moment. I've been away from that world for a while. What I'm working on now is, although it's certainly inspired by some of the technical roots of some of the things I've done, I'm not that was doing geo-based games. I think things like Ingress and Pokemon Go are scratching the surface of what I think is possible in that space. And I think there's some very exciting possibilities there that are woefully underexplored. And I'm really surprised that there hasn't been more sort of experimentation in that area. As far as what's going on right now, I don't know.

I've been unplugged from the games world for a while. I am sort of increasingly down in the weeds of the technology stack. And, you know, it's a happy place to be because you can just have sort of more control over your universe there. Why don't you elaborate a little bit? What are you up to now? What's been your recent focus? So I'm currently working for a company called Agoric, which was started sort of community of folks who have been in each other's business on and off, in and out, in different permutations and combinations over the years,

in various different startups and companies doing things. And this is sort of one of the latest manifestations of that. Some of the people that I'm involved with in Agoric were early people at Xanadu going back to the 1980s. And so I have sort of deep roots and attachment to a lot of these folks, which is, on the one hand, it's really great because we can trust each other, utterly kind of know each other's habits of thought. It also means, you know, we're kind of a bunch of OG guys sitting around saying, okay, you kids get off my lawn. So Agoric is a blockchain company doing smart contracting. Another place that I spent many years at was something called American Information Exchange, which was one of the first e-commerce companies doing person-to-person

commerce for the first time. And sort of the more modern manifestations of that would be things like PayPal or eBay. And Agoric is sort of the latest evolution of that doing what are called smart contracts, which are contract-like arrangements between parties, which are enforced by a computational system in the middle. And we're using the blockchain so that you don't have to have a trusted third party. The third party is more of an emergent phenomenon. We're kind of a peculiar blockchain company in that we're not really cryptocurrency maximalists. We're more, here's this useful technology for dealing with some fundamental

security and trust problems. There's a lot of really interesting distributed system stuff in doing that. The particular piece that I work on is the kernel that underlies distributed computation framework, which we use. And the whole idea there is to provide a trustworthy computation environment. And that involves some really interesting, I don't want to say breakthroughs in security technology, because it's really technology that's been around since the 1970s. but the use of some techniques for achieving security, which are kind of cutting against the grain of the mainstream of thought in computer security. I kind of, when I'm feeling grumpy, kind of liken it to the state of computer security is kind of a mess right now. You think if we were learning things that systems would be getting more secure over time, and the history of medicine in the 19th century, where we're just starting to understand the germ theory of disease. And there were a few kind of lone voices in the

wilderness who were saying, hey, doctors, you know, wash your hands. And all the doctors were like, what? That's gonna make the miasma fall off. Yeah, or whatever. But basically, I think there is something similar to that, which is sort of the dominant paradigm in a lot of computer security infrastructures is what you call identity-based access control or ACLs, which is access control lists, where the fundamental security operation is to ask, well, who are you? And then based on who you are, we make a decision about whether we let you do or not do a particular thing. And this turns out to be a fatally flawed basis for building secure systems. So our system is built on something called object capabilities,

which is much more oriented towards the question of, well, what can you do? And what authorities do you possess? What powers do you have in hand that allow you to do things? And this enables us to build secure distributed systems that are much more resistant to a lot of the traditional kinds of attacks that these systems tend to be subject to. There's another thing I've written about at greater length on my blog. So I'm trying to wrap my head around this. So usually you would have a list of users. These could be employees at your company or what have you. And then you have a list of groups. And so the permissions are on the group. And so if I want to get on the development cluster, I need to be in the development, you know, engineers group, right? And so, but it's all, you know, at the end of the day,

it's all like a MySQL database somewhere that just has a list of people and the groups they're in, right? And so what is what you're doing different? Yeah, so if you, sort of the classic model is what they call an access matrix, where you have a set of parties or people or things, and then a set of resources that you want to have access to, where the

resources could be files or they could be computer logins or whatever. And the question is, which of these is sort of the primary entity for managing this? And the access control list model is that you associate permissions with users. The capability model is that the resources themselves are the thing that are really important. So one way to think about this is think about, so you're editing a document in Microsoft Word, let's say, and you hit the save button and it goes to write your file out. And it asks the question, well, does this user have the authority to write to this file? And it does because it's your file and you have permission to the file and everything works. But at the same time, you have the authority to write to all of the other files that are on your

system. And this program that you're running could just as well take your file and ship it off to a server run by the mafia in Macedonia and send all of your secrets away and you wouldn't know the difference. And so the question is, why does this piece of software that you're running, and it could be Microsoft Word or it could be the Solitaire program, have the authority to sell all your secrets on the internet to the highest bidder. Because it does. The reason you mostly don't worry about that is because if Microsoft Word did that, like Microsoft would get sued. But in fact, what you're really running when you're interacting with some piece of software is you're interacting with an entire stack of stuff.

So you're browsing the web. you've got the web browser, you've got the page that's loaded. You've got that page is filled with a bunch of JavaScript that came from, you know, a hundred different providers in different NPM packages. You've got the, the, the operating system that you're running. You've got the server that you're talking to, and it's composed of a bunch of components that came from a jillion different sources.

And are you really want to say that every single one of those components has the authority to act as you? You know, that seems like a very sketchy foundation for... Yeah, but you see this all the time with these like poison pill versions of software where there's like uh you know there's a a library that just draws charts and so you have a website and you know you have this chart library and then someone releases a poisoned version where when your web server loads that version of the chart library,

it actually dumps all your passwords out. Well, there have been a number of supply chain attacks, particularly through sketchy NPM packages, where there was quite a notorious thing a few years back where somebody managed to take over maintenance of some some minor package that was being used for some purpose but it didn't require a lot of maintenance and suddenly volunteered to take it over from the the person who had had created it who was happy to give it give the the chore to somebody else uh and they inserted a bunch of stuff that would sort of troll through your system to see if you were using a particular cryptocurrency wallet. And if it did, if it found that stuff, it would then take your various credentials and ship them off and allow somebody to get into your crypto wallet

and steal all your Bitcoin. These kinds of supply chain attacks are increasingly of concern. And in a sanely constructed computational environment, these things would just not be possible because it wouldn't matter what code you loaded because that code wouldn't have the authority to get at this stuff in the first place. And therefore, it didn't matter how malicious it was. It literally does not have the authority. It does not it was it literally does not have the authority it does not have access it does not have the capability to get to the things that you were you were profiling to prevent it from getting to because i mean it sounds it sounds like snap uh snapcraft or docker these kind of things i mean not not literally but it sounds like uh spiritually

similar where like uh you know, in Snapcraft, you actually say, you know, this package, this Unix package will only run a server on TCP port, you know, 2048. And so, you know, if it tries to run a server somewhere else for some hacker to go and get all of your data, Snapcraft just won't allow it. And same thing with Docker.

You have to forward ports and everything. Right, and this is sort of a much more, the whole object capability approach is much more sort of structured and disciplined way of doing that. The model is in a good memory-safe object-oriented programming language. And ironically, we're using JavaScript,

which for weird accidents of history, it turns out, although many, many of the things which are JavaScript is notorious for being basically a sieve with respect to security, with being infinitely malleable, sort of infinitely malleable properties, meaning it's almost impossible to securealleable properties meaning is almost impossible to to secure regular javascript out of the box but in fact there goes our chance to have brave

as a sponsor for this show is a is a is i'm not sure what they quite but the relationship is but brendan eich is an advisor to our company uh nice fans of brave Fans of Brave, and Brave, they've been big supporters of ours. Yeah, no, I'm kidding. I mean, actually, it would be great if Brandon could come on the show. JavaScript, for historical reasons, turns out to be, unlike almost every other programming language on the planet, sort of uniquely possible to secure. You can actually carve out a securable subset of JavaScript, which can be, whose security properties can be automatically enforced in a reliable way, in a way that allows the vast, vast, vast majority of the existing software and tooling in the module ecosystem to continue to run out of the box without modification, assuming it's not doing anything malicious. And you can actually

build a secure programming environment out of JavaScript, which is different from almost every other programming language on the planet. And because JavaScript is in fact securable, it's not secure in and of itself, but it is securable, we have built a secure version of that, which we call hardened JavaScript, which enforces all of the object capability security properties, which are necessary to actually build secure systems and and this is what we're using for our smart contracting platform wow cool is that um hardened javascript like an open source project or is that everything is all open source and our objective in is is to eventually have all of the various things which make Javascript hardened

eventually make their way into the official ECMAScript language standard. And we've been very active, we and our founders and various people in Agoric, starting from long before Agoric was founded, have been very active in the TC39 committee, getting these things which make JavaScript securable and then the tools to actually secure things

incrementally incorporated into the standard. And there's still a few pieces to go, but we have made very good progress on that. And I think the prognosis is quite good. We will eventually be able to create secure compartmented object-oriented programs. Wow, very cool. So jumping to GORIC a little bit as a company, what is something kind of unique

about... Well, actually, before we do that, is Agoric hiring? I know that it's a strange economic time, so I probably should ask that in advance. Yes, we are hiring, actually. I'm not sure what I'm allowed to say in terms of how capitalized we are, but we're comfortable for a while, and we're on a growth path, and we are hiring. We need some engineering people. We need some product marketing and support people. If you go to our website, agoric.com, there is a link for careers and it will tell you what openings we currently have. Got it.

Are there intern positions? We have a lot of folks who are still kind of in the middle of school. I do not know. Okay, we'll look that up. We'll see if we can add it to the show notes. What is one kind of unique thing about working at Agoric? It could be everyone plays ping pong on Tuesdays. What is something that makes Agoric kind of different? Wow, that's a really interesting question because it is very different, except that it's what I think of as the normal way companies should be. It's just that very few of the companies that I've worked for that I haven't been one of the founders of have had the quality.

There's a lot of people who are... When I've been interviewing people for engineering positions, the quality that I look for, which is a degree of, I don't know if you want to call it engagement, or the sense that there's a person there that you can talk to and have conversations about deep things and people who are actually sort of, it is sort of part of the core essence of their being that they're interested in solving these hard problems. And they're just interested in learning about stuff and figuring out how to do stuff. Yeah, that makes sense.

There's a phenomenon that one of our other founders who used to work for a big company in the Pacific Northwest, let's just say. Okay. I think I've narrowed it down to two, but go ahead. Referred to as smart guys with a job where he encountered people who are perfectly intelligent, perfectly competent and capable as engineers, knowledgeable, but this is their job. This is the thing that they did. They do it fine, but it's kind of not what defines their being. We have a lot of people who, this goes to the core of who they are. A lot of that means that people are very interested in how stuff works,

in solving problems, and engaging with difficult technical problems just because they can. Yeah. How do you select for that? I mean, sometimes when you're talking to somebody in an interview, you can kind of pick up on that. But is there a systematic way that you can select for that? It's hard. I think it's possible because I've been the founder of a number of startups and this is a quality we look for, but I don't have a magic formula. Part of it is I know it when I see it, except that I don't really, because I know I've kind of hired people and it turns out that they didn't have this quality. Well, it might be, we don't know what the baseline is.

Like your yield might be higher than average. It's not going to be 100%. That is true. I think there is this, as I say, this quality of engagement where you put a problem in front of somebody and they're interested in it, sort of in and of itself.

There is the kind of person who thinks about the future, thinks about what would the consequences of this thing existing be on the world. It's really quite astonishing to me the degree to which people have difficulty visualizing how something would be if it were different. If you were to introduce some capability to the world that wasn't there before, how would things change? And it's not so much that people necessarily get the right answer, but that that's an interesting problem. And they like thinking about that. And not just that they like like thinking about that but they can't not think about

about that yeah one thing i noticed is is uh to your point at some of the i've never been working i've never worked in the pacific northwest but i've worked in northern california and um yeah i think what what you're getting at is like a sense of agency or at least that's part of it is a sense that like you know look if i if i implement this thing that's going to cause some change versus like you know boss gives me code to write i write code for boss and then the system is just rolling forward there's there's like i think like one of the things i see a lot is people who read a lot of science fiction it conditions them to think about how the future could be if different things happen.

When back in the early days of Xanadu, I spent a lot of time traveling around the country giving presentations about hypertext. Nobody had any idea what this was. The reception I get was generally very positive. But then people would ask weird questions like, why would you want to put documents online? Who's going to pay to make all of these hyperlinks? Right, right. Which are just like, what? And no one who has spent five minutes with the World Wide Web would ever think to ask

those questions because obviously that's just not and not how things would work. And people would have difficulty visualizing, if I had all of the world's knowledge at my fingertips, what would that mean? And it's not even necessarily that they, as I say, that they know what that would mean, but that that is clearly an important and transformative thing if it were to happen. That's really, just like double down on that, you know, I got my PhD in playing Go

with neural networks, which, you know, like in hindsight, it's like, okay, neural networks clearly were the right answer there. But I remember, you know, I remember, you know, like my parents, other people saying like saying like like who really cares if you play really good go like i don't even play go right as a human so but i but but to your point it's like i could just feel that there was something powerful about this game that is so similar to chess these other games but it's just completely intractable. And if you could crack that, it was, there's something powerful there. And part of it is just, it's like, you know, the draft, like a draft is not fast. It's not really agile. It can't hide, but it can reach

that fruit that no one else can reach. And so that earns it its place or an ecosystem and so like go is like this really high up kind of fruit and i just felt like there was something powerful about being able to crack that and it's just like to your point like you can't i can't tell you yes we're going to turn go into being able to sell someone like a toyota on on an ads website like i couldn't do that but i just knew that there was like something there, right? Well, one of the things that really struck me when chess kind of fell to computation, let us say, many years ago, there were a lot of chess people who were kind of like, well, that's it. You know, chess is over.

It's done. It's a solved problem. How depressing. And when they kind of cracked Go, the reaction was much more like, oh, this is really interesting. And there were all of these Go enthusiasts who said, oh, this has revealed an entire new space of exploration that we hadn't looked at before. Wow, this is really interesting. And they kind of saw this not as they had been displaced, but rather that a whole new space of possibilities had been opened up for them. And I think that the disparate reactions there are interesting. I'm not really

sure what it means, but there's definitely something about technologies that are enabling. I'm not really a technology determinist, but it's very clear to me that much of what has propelled the advancement of human civilization the most effective ways you can do that is by expanding the technology palette that we have to work from. And I get very frustrated with a certain kind of person who pushes against that. It's like, oh, no, no, no, technology is the source of all of our problems. And it's like, well, yeah, but. Well, it's like oh no no no technology is the source of all of our problems and it's like well yeah but well it's it's both it's the it's the source of all of our problems and the source of all of all of our solutions or at least a large percentage of them right it's like uh you know if we didn't have technology i could sit here with this uh you know purified water and this uh food that i got for first enormous supply chain and just be happy you know cool so this this is amazing i think uh you know definitely folks check out check out agoric

if you uh actually so what background on the engineering side what sort of uh skills uh is agoric looking for is it is front-end, back-end? Is it C, JavaScript? It's mostly JavaScript, although I think the fundamental thing we look for is, can you program your way out of a paper bag? All right. Which is, and this is something that's a sort of over-specialization, particularly in programming languages, where somebody says, well, I'm a C++ programmer, or I'm a JavaScript programmer,

or I'm a front-end person or whatever. And I think the more fundamental question is, can you solve problems? Because in this industry, it's programming language of the week. And if it's JavaScript today, it might be Rust tomorrow or it might be something else that you've never even heard of that hasn't even been created yet the week after that. And so people have been doing this for a long time, you know, often, you know, have adopted the perspective of I've got a new set of tools that I'm going to use to do this new job. And I'm going to spend the first part of this job learning to use those tools. And so what I need to be able to do is to acquire this new tool set

as opposed to, well, I know how to use this one thing and I'm going to market myself as a person who's an expert at using this one thing. Yep, that makes sense. Yeah, totally. So cool. So yeah, so if this sounds exciting to you, if hardening JavaScript, working on these sort of, you know, kind of blockchain based security protocols, check out Agoric, check out the product that they have and also check out the careers page and and and see sort of what opportunities are there. One of the visions with the GORIC is

we're all about, we talked about smart contracts, but really what's about is lowering the costs and risks of cooperation among dispersed parties. The vision is that if we can lower the cost,

lower the risk of cooperation, we get a more cooperative world. A more cooperative world would be a better place. Cool. Yeah, that makes sense. That's a perfect way to end the show. So I think if folks want to reach you, Chip, they can reach you on Twitter. It's at E-P-O-P-T.

We'll put that in the show notes. There's also habitatchronicles.com. We'll also put that in the show notes. And if you're using folks out there, if you're using Podcast Addict or any of these podcast things, I've started putting the show notes right there in the RSS feed as well. So you could always go to programmingthrowdown.com, but you'll also be able to get all of these links straight from most of these podcast apps. And if your app doesn't have it, let me know and we can work on that. So thanks everyone for supporting us on Patreon and through Audible subscriptions. We really appreciate that. And thank you, Chip, for coming on the show. It's been really fascinating. We ran through a gambit of different things.

You know, one of the last things, I'll let you have the last word, but one of the last things that I've noticed is just how diverse your background has been from, you know, you worked on so many different things. And I want that to really resonate with people. You know, I think that somebody recently asked me, you know, do I, am I going to sort of like, am I nervous? Because, you know, full disclosure, I'm 40 years old. I guess that's what over the hill. I don't know what you call 40, but I turned 40 this year. And so I said, are you worried that, you know, you won't be able to continue being an engineer? And I said, no, I said, you know, you won't be able to continue being an engineer?

And I said, no, I said, I'm going to be an engineer until like they just, you know, carry me out feet first and I'm going to be competent the whole time. And, you know, I think it's because, you know, I'm constantly learning new things and doing different things and part of a variety of different areas. And that's what it means to do engineering for many years. And so I think, you know, looking at kind of your career, Chip, you've also kind of been in many different areas. And I think that's really something that people should take home. Yeah. And I think to the comment you just made,

I mean, I'm 63, and I still have the same sensation that you just described. I have a, age discrimination is a real thing in Silicon Valley. I have a venture capitalist friend who views hiring older engineers as one of his secret weapons.

Nice. Because the people who engage in age discrimination are stupid. Well, any, yeah. Anything is going to create arbitrage, right? Yeah. Yeah. And I, yeah, I'm, I'm, I'm, I'm going to be doing this until they carry me out feet first. And hopefully, you know, we have a whole cohort of folks who's, who's, you know, position is, is, you know, we're going to live forever or die trying. Nice.

And, you know, and we're working on that problem, too. All right. Cool. Great. All right, Chip. Thank you so much. I really appreciate you coming on the show and your time. Great. It's been a delight. Thanks. attribution share alike 2.0 license you're free to share copy distribute transmit the work to remix adapt the work but you must provide attribution to patrick and i and share alike in kind