Matias Pan: I think it’s interesting, because it’s a context that probably a lot of people are finding themselves in. A lot of companies went through really crazy hyper-growth, and then all of a sudden the bear market hit, and they were left with this application that grew very rapidly, with a team that probably didn’t know much or at all about infrastructure, and a really big team, but not really all that amount of money that they can use to continue growing. And when you get to that point and you want to continue making your product better - because you’re not reaching hyper-growth, you’re reaching for the classical breakeven, or in a way making your product profitable - you will have to make a lot of decisions regarding your architecture and your infrastructure, that they all have to keep in mind that what you want to do is reach that breakeven. You want to actually be able to continue to deliver value to users, and hopefully, that value gives money back to you, and you can keep the company running.

So when I joined Lemon - Lemon Cash is the full name of the company - that was the exact context in which the company was in. There was a really, really big, monolithic codebase, that had so much code, from so many different domains. We’re talking about a bank/crypto, so it has a lot of things related to a bank, but it also breaches you into the crypto world. And not just like tokens, not just like currencies, but also like NF Ts, and the entire gamification that the crypto industry is trying to bring.

[05:53] So this was a big up. A lot of very clear, separated domains in this single place, and the entire infrastructure in which this was laid on was not something that happened on purpose. So it wasn’t far off. It was “Hey, we have to get this to production now. What do we know about it?” “Not much.” “Okay, there’s this thing called ECS, that they’re saying it’s serverless, and they’re saying it’s super-easy, and there’s this blog post that a big company wrote. Let’s just use that.”

And then when I joined, the company grew from 5 developers to 300 people, which brings a lot of really different problems where you’re working on that monolithic codebase… And the idea of going to a service-oriented architecture was kind of natural, in a way. And when I say natural, I don’t mean that it’s the obvious choice. It’s going to depend on what context you’re in. But we’re talking about a bank that has the most critical thing at hand, which is money. And you always want that bank to work perfectly. So for a bank, the idea of services allows you to separate the failure domains in a very clear way, and make sure that the product is the best thing that you can do.

So yeah, the decision itself had already been taken, and when I joined, they were already discussing about going into a service-oriented architecture. But there were no discussions around the infrastructure side of going to that architecture. And for me, at least, that’s the biggest problem you have to at least think about and solve in part, before actually committing to that. It’s perfectly fine to start separating the code, understanding the domains and doing that exercise, but when you want to actually execute that, solving the infrastructure part, the observability part, the monitoring, how you get things to production, how you operate on those services, how do you have on-call policies - everything related to having a service in production also needs to be discussed.

So that’s where this proposal that you mentioned came to be. It tries to tackle how you should be deploying services, at Lemon specifically - that’s why it’s in the title - and it puts that in the context of all these other things that we also have to solve in order for the company to operate services gracefully, I would say, in production.

Shawn Wang: That is a short-term business model, yeah. I bet they have much more up their sleeves… I don’t actually know. But they did just hire their first developer advocate, which is interesting, because I think you’ll start to hear a lot more from them.

[58:12] Well, there’s two things I will offer for you. One, it’s a very common view or perception that AI is a centralizing force, right? Which is, Adam, what you’re talking about, which is, “Does this just mean that the big always get bigger?” Because the big have the scale and size and data advantage. And one of the more interesting blog posts - sorry, I can’t remember who I read this from - was that actually one of the lessons from this year is that it’s not necessarily true, because AI might be a more decentralized force, because it’s more amenable to open source… And crypto, instead of being decentralized, turned out to be more centralized than people thought.

So the two directions of centralized versus decentralized - the common perception is that AI is very centralized, and crypto very decentralized. The reality was that it’s actually the opposite, which is fascinating to me as a thesis. Like, is that the end game, that AI eventually gets more decentralized, because people want this so badly that there are enough researchers who go to NeurIPS to present their research papers and tweet out all this stuff, that diffuses these techniques all over the place? And we’re seeing that happen, helped in large probably by Stability AI. The proof that Stability as an independent, outsider company, like not a ton of connections in the AI field, did this humongous achievement I think is just a remarkable encouragement that anyone could do it… And that’s a really encouraging thing for those people who are not FAANG and trying to make some extra headroom in this world. So that’s one way to think about the future.

The second way to think about who monetizes and who makes the billion dollars on this… There’s a very influential post that I was introduced to recently from Union Square Ventures, called “The myth of the infrastructure phase”, which is directly tackling this concept that everyone says “When you have a gold rush, sell picks and shovels”, right? And it’s a very common thing, and presumably AI being the gold rush right now, you should sell picks and shovels, which is you should build AI infrastructure companies. But really, there are tons of AI infrastructure companies right now, they’re a dime a dozen; really, they’re all looking for use cases, and basically, the argument, the myth of the infrastructure phase is that technology swings back and forth between app constraint and infra constraint. And right now, we’re not infrastructure-constrained, we’re app-constrained. And really, it’s the builders of AI-enabled products like TikTok that know what to do with the AI infrastructure that can win.

So I’ll introduce those concepts to you… I don’t know what specifically that means. I’m looking out for opportunities like that myself. But I think it’s apps; I think it may not be infra, because it’s going to trend very, very hard towards commodity infrastructure provisioning, and I don’t really care where I get my A100s from… A100 being the predominant NVIDIA chip that is being used to train all these models… Which, by the way, costs $200,000 per chip, which is insane. Imagine a GPU costing that much.

Suz Hinton: Yeah, I think I did a mix of them. So I did CCDC, which is the Collegiate Cyber Defense Competition. I did that with a team, and that was just the defense side of what you just said. So they do hire professional red teamers, and they’re a team from every single college that’s participating. And there’s eight of us, and you have to lock down – they give you an incredibly vulnerable network. The gist of the story is they’ve just sacked the entire IT team, and they’ve hired you on as the new IT team, and you have to basically audit the whole system, find out how it’s vulnerable, lock it down… So it’s the same as what you were saying, but we don’t have to attack anybody. But you spend the first day just auditing, trying to lock things down. They interrupt you with business requests constantly. So you’re emailing the CTO, he’s like “Oh, I want you to look into crypto as a product. Can you give me a report on crypto by the end of the day?”, or something. And so they’re constantly interrupting you and trying to simulate a real business environment where you’re just fighting for your life.

And then yeah, like you said, if they just find one vulnerability, which they will, all of a sudden you’ve got choo-choo trains on your console, and then certain other boxes are boot looping, and you’re just like “Oh, my God… It’s an actual fire right now.”

And so that was a very stressful one that I did, but the others were more about – they’re trying to give you experience with everything in cybersecurity, so there’ll be an encryption section where there’s puzzles. They’ll give you a bunch of encrypted text and they’re like “What does this say?” And it’s more about answering the questions, and completing as many of the challenges as possible. And they’re just smaller toy challenges. And they’ll also challenge you to actually get into a box, for example, and then yeah, find the flag and report what the flag was. So I’ve done a big mix of them.

And then there was the reverse-engineering one, which was NSA, and that’s totally different again. Yeah, it’s been a variety. I think I like the ones where I can just sit and tinker… But the cyber defense one - I really feel like I leveled up, especially in Linux. We spent months practicing, and running password reset drills, and things like that… And being able to audit – and we had this big notebook we were all throwing notes into for each other, and we were on a Zoom call for the entire weekend, talking to each other… It was very high stress, it took me a few days to recover. But I really feel that it forced me to level up, and I’m sure you felt similarly, Jerod.

Jerod Santo: Yeah, absolutely. So the background story is that we had a newsletter for many years called Changelog Weekly, which you would subscribe to on Changelog.com/weekly. We also have a nightly newsletter, which is still going, which is an automated scraper of the most starred repos on GitHub, which is increasingly becoming simply AI, crypto, and malware. So it’s getting to be less useful than it used to be… But that one goes out weekly, it went out weekly, and that’s why he named it Weekly. Right, Adam? We had a hard time coming up with a better name for that, because well, we already had Nightly, and Weekly, and… And it was what it was. And then we started the Changelog News podcast as a flavor of the Changelog… Which was quite a success, a hit. People liked it, we like to do it, so we kept doing it, and we decided to streamline the newsletter, and the podcast, send them out at the exact same time… They were already complimentary; let’s just make them more efficiently complimentary. And so Changelog Weekly became Changelog News, which was just both a podcast and a newsletter. People who are listening to this pretty much already know that.

The technical side of that was that the podcast became its own podcast in our system, and had a podcast page just like all the other ones, just like Ship It’s page, just like JS Party’s page, etc. But it had this newsletter component that wasn’t very well featured, basically.

So when you’d go to changelog.com/news, you would find the Changelog News podcast, and there’d be a subscribe button with newslettery things… But we weren’t featuring the newsletter at all. And so this redesign was an effort to have a different page that lives on changelog.com/news, that serves both the podcast and the newsletter better, in terms of people understanding what we’re doing there, being able to quickly read the most recent issue… You know, give it a better splash page. Because lots of people land on that page, and we want them to know what it is. And it’s more than just a podcast. So that’s the backstory.

A couple of shout-outs. Of course, Cody Peterson, who worked with me on the design and the frontend implementation of the new splash page. Shout-out to me for coding it up and opening up an epic PR, which I don’t normally do… And to a handful of folks who decided to send us kind words to use on the page. We have a lot of people who enjoy the podcast, enjoy the newsletter, and they tell us this privately via email and stuff, and so I reached back out to everybody who reads it and said “Hey, if you would give us a quote, we’d like to put some of those on the homepage.” And so shout-outs to Mary, to Justin, to Chris, to Maros, and to [unintelligible 00:17:57.09] whose quotes were awesome. And we got more than those, so thank you to everybody who sent one in. Those were the five that we selected to feature on the homepage. And that’s pretty cool.

[00:18:15.23] Being able to hear from and see some of the people who take value in the newsletter I think is powerful when you’re trying to decide – like, two things you want to know. A, do people like this? And then B, what does it look like? Show me a recent issue. And I think with this redesign that we’ve accomplished that. So that’s that.

Kris Brandow: That’s kind of like asking “Shouldn’t everybody just write their own crypto?” It’s like, no, this is a very specialized skill set, that people get PhDs in, and it’s very difficult work, and you should hire somebody that’s trained in how to do that thing… Especially if it’s an important thing to your organization, which if you’re going to be writing thousands to tens of thousands or hundreds of thousands of lines of code, and you need to manage that asset you have, you should probably ensure that you have a lot of knowledge about what went into creating it, and the history of that.

Paul Vixie: I would like to say so. [unintelligible 00:35:26.26] ever taken on something that was going to be clearly possible… [unintelligible 00:35:31.23] And at the time, I left nonprofit service and went back into the commercial world in 2013. I was trying to do exactly what say. I was trying to figure out “Well, if there were a replacement to the DNS protocol that you could opportunistically adopt…” So you as an information publisher, you as let’s say a smartphone maker, just creating a lot of DNS requests, you’re going to fetch a lot of information, and just try to enumerate all the different entity types in the entire DNS economy, and say “Well, how could they speak both for some transition period”, which by this time is 30 years, “but anybody who was an adopter would immediately get some improvement [unintelligible 00:36:21.16] performance, less resource use”, whatever it is that would be the incentive to adopt. And in a way, that’s how HTTP/2 and now QUICK (HTTP/3) are doing it. And so I was really tinkering hard with this, at the time that I just kind of said that “That’s it. I’ve done 18 years of nonprofit service. I need to go think about my retirement” and I went back into the commercial world.

But I’ll tell you, the biggest impediment to this is that everybody wants to be the creator of that. So you’ve heard of crypto, and Bitcoin, and digital currencies… All of them followed each other along this model of “We don’t like the fiat currencies. We want to be able to have money via a matter of private contracts, without governments being able to either inject money into the economy, or control interest rates”, or whatever. And the problem is nobody [unintelligible 00:37:21.09] came in later and said “It’s a really good idea. I’m going to adopt [unintelligible 00:37:26.02] most popular.” What they did is they came in and they said “Whoever owns this is going to be a trillionaire”, and they created [unintelligible 00:37:32.20] Why would you use an existing one instead of submitting your own?

So some of those very same people have come along and said “Yeah, we could use the blockchain to encode domain names, so that takedown was impossible. So that no matter whose trademark you were infringing, or whose intellectual property you were infringing, there’d be nowhere to target a lawsuit, as you [unintelligible 00:38:00.03] There’d simply be nowhere to go to request takedown. And wouldn’t that be better than having government? I’m not sure it would be, but I’m pretty sure that that type of anarchy might do more harm than good. [unintelligible 00:38:18.25] opportunity.

Roland Shoemaker: These are old – not old, but these were major X.509 changes that we made for TLS – the authentication layer of TLS uses X.509 certificates, and X.509 uses an encoding language called DER, the Distinguished Encoding Rules… Which we’ve had a – Adam Langley, who wrote a lot of the original crypto libraries, wrote a parser for it that uses reflection, which is something we offer in Go but is… I can’t say terrible, but it’s quite slow. It’s a very interesting language feature, but it’s kind of painful. And he wrote it using this because - he said to me, the reason he wrote it using reflection was he had never used the language that had reflection before, and he thought it would be an interesting thing to use reflection for.

Nathan Sobo: But just from a personal perspective, it’s not like I surveyed the landscape and was like “Let me find a low-hanging fruit to pick.” It was much more the perspective of “I’ve been trying to do this for 10 freakin’ years, still haven’t managed to do it, and nobody else has either, and so I just have to keep going.”

Now, you’ll have to talk to our investors for their particular motivations, but I can tell you what I told them, and really believe, in terms of what the market opportunity is today, in terms of - again, I think if I were in this for the money, I probably would have started like a crypto token, or something. That would have been a faster route to riches. But I do think it makes sense to build a business model around this.

And for me, the opportunity is really about how we all communicate around code. I mean, I worked at GitHub for nine years. I love GitHub, but I also don’t feel like there’s been substantial innovation, since pull requests came out all those many years ago. And I think it made sense at the time to kind of hang this social layer on top of the version control artifacts. I just think we can take it much further. I mean, that’s what I pitched Chris on, to kind of get hired at GitHub, and we didn’t manage to pull it off… But now I think, based on everything we’ve learned, we’re actually positioned to do that.

[44:00] And so what I really want is a world in which having a conversation about any line of code, whether it was written a couple of years ago, or I just wrote it and I haven’t even hit Save, is something that just feels like at my fingertips; I can @ mention a teammate, pull them in, and start a conversation, so that conversation is really growing over the entire codebase. Because again, you want to introduce a new feature - that probably interacts with some other layer of the system that you may not understand. Already, you need to start having a conversation. But do you do that on a pull request? You haven’t even written one line of code yet. You’re just trying to understand what’s going on.

And so there’s just so many things like that, where it would be a great idea to have a tool that really facilitates interaction around code, and it just doesn’t exist. Like, I don’t know what we did; we’d like paste code into Slack, or like cap things inside of backticks. You’re talking about code that isn’t even there, and then it scrolls off the screen, and it’s gone forever when someone else comes to the code and has the same exact question that you had. Or are you hopping on a Zoom call and now one person’s like dictating through the screen, like “Oh, no, no, no. Okay, open this file; okay, now go to this function…” Whereas already in Zed we’ve tackled the real-time piece of it.

When we want to just have a conversation about code, we’re doing that in Zed. Start up voice, that’s not in Zed yet, so we still rely on an external tool to do the voice for us. But then I’ll just open up a submenu, invite one of my teammates in, and we’re following each other around inside the code, instead of trying to dictate through the screen, like “Go here. That – take that”, because the latency is so high, or whatever. I’m just moving around, and they’re following me, and then they’re moving around and following me…

I remember, when Mikhaila, an engineer on our team - she was like integrating the terminal into Zed; she was interacting with GPUI, and there might have been some APIs missing; she wasn’t quite sure. So we had a conversation, and I toured her around inside the GPUI, which I wrote the majority of, and then I followed her, and she toured me around inside of the terminal code, and then I got a sense of what she was trying to do. And then I jumped back into GPUI, and we wrote the code, added the methods together that needed to exist for her to accomplish what she was trying to accomplish. Then we hop back into her code, which she knew much better than me, and used those methods. And within an hour, with a quick conversation, we accomplished what over pull requests would have taken a week, I feel like.

And so that’s the level of fidelity that we’re looking to bring to interaction around code, starting with real time, but not confining ourselves to that. That’s, I think, the innovation opportunity; it just so happens that the primo kind of iPhone, Apple vertically-integrated product that delivers that experience in my mind is the tool in which the code is written itself. That you shouldn’t be Command+Tabbing out to a browser; that that experience should be tightly integrated directly into the authoring environment, just like it is with Figma, or Google Docs, or these other disciplines, that the place to collaborate and talk about code is where you write it. So we have to build a great code editor. But luckily, I want to do that… So that’s our competitive insertion, and that’s the business part that we want to build.

If you want to use it by yourself, I want you to do that and do it without paying us a dime for it into the future. And I want to build a business around teams using this tool to be more productive by having a better mind meld with each other and being more effective in our communication. That funds the people that just want to use it by themselves for free, and drives more innovation into the code editor space than has ever been possible, ever been funded.

Mitchell Cohen: They were a hodgepodge of different things. And that’s true about any sufficiently large piece of software - you end up with all sorts of bits and pieces built over the course of years, kind of connected together. But one issue was that they all felt very different. So the way I started to think about it was it almost felt like someone was making third-party, fan clients for our service, even though we were the ones making them… And definitely, that was something on our minds when we set out to build our new tech stack, and of course, our new design language and feature set that accompanied that tech stack.

But the other interesting thing about them is that they also all had web technologies in them, and we always have used web technologies heavily and pioneered them… So as Andrew already alluded to, we used web crypto very early on to power our web service and to make sharing possible over the web. But even on the desktop apps and mobile apps, we had web views, we had web-based integrations. And in fact, the most important part of our desktop app, which people interact with every day, has always been web-based and very heavily so. And that of course is the browser extension.

[16:16] So it’s interesting to see people think of what we’re doing as sort of like a move, or a shift, when really it’s just taking something we’ve always cared about deeply and continuing to use it in our product for the things that appeal to us about it.

Nader Dabit: Yeah, and another thing that I think is a huge deal, that maybe had a lot to do with the interest that was there was that - to me, up until (I would say) I started following other people in the Web3 space, I felt like the communities were very siloed. Either that, or I just was completely unaware of what was going on… But I could probably point to a time late last year where my entire Twitter feed for days, weeks or months even wouldn’t even really mention anything about blockchain, or crypto, or Web3… And that has completely changed now. Of course, I’ve started following a lot of other people, but I think also what that told me was that there wasn’t a lot of overlap between the communities.

Mitchell Cohen: They were a hodgepodge of different things. That’s true about any sufficiently large piece of software - you end up with all sorts of bits and pieces built over the course of years, kind of connected together… But one issue was that they all felt very different. So the way I started to think about it was it almost felt like someone was making third-party fan clients for our services, even though we were the ones making them… And definitely that was something on our minds when we set out to build our new tech stack, and of course, our new design language, and the feature set that accompany that tech stack.

But the other interesting thing about them is that they also all had web technologies in them, and we always have used web technologies heavily and pioneered them… So as Andrew already alluded to, we used web crypto very early on to power our web service and to make sharing possible over the web. But even on the desktop apps and mobile apps, we had web views, we had web-based integrations… And in fact, the most important part of our desktop app, which people interact with every day, has always been web-based, and very heavily so… And that of course is the browser extension.

It’s interesting to see people think of what we’re doing as sort of like a move or a shift, when really it’s just taking something we’ve always cared about deeply and continuing to use it in our product for the things that appeal to us about it.

Alexander Neumann: Initially, I started with the 0.something releases to be able to at some point say like “Okay, at this point we break the repository format and we add something or change something that’s not backwards-compatible.” But this hasn’t happened the last couple of years. The most important thing that I think in terms of the backwards compatibility for the repository would be to add compression. Restic does not support compression yet, because the data would need to be compressed before it is encrypted by Restic. So you need to have something built into Restic.

I can see a way how to add compression to a repository, but this would break compatibility with prior versions of Restic who don’t know about compression. Once we add that, i can think that it would warrant a release of 1.0, or something like that… Like, okay, before we had everything was compatible, and you can even use the newer version of Restic to restore from old repositories… But whenever you initialize a repository with 1.0 and have compression support, then you cannot restore with an older version. We also have a version field in the repository, so Restic can even give you a nice error message that it’s unable to understand the repository format because it’s too new. So this would, I think, warrant a 1.0.

Unfortunately, changing the repository format can open a can of worms, because there are so many things that could be made better… And personally, I started working on this, but I’m not sure where to stop. Like, do I just add compression, or do I also add support for error correction? Whenever you have a file where there’s a one bit flip and you cannot restore this chunk in this file, because there’s a bit flip, and the signature doesn’t match anymore, and Restic says “Okay, the ciphertext verification failed because something is wrong” - it would be nice to have, for whatever correction, as Reed-Solomon called, for example, where you make every file 10% bigger in order to be able to correct one or two bit flips. This is an interesting feature to have, but does it warrant another repository version, or do we do this in one step? And I’m not sure where to go from there.

[01:00:04.18] On the other hand, changing the repository format is not an easy thing to do, because you have to keep so many things in mind… And until somebody else steps up and really does that to my liking, I don’t think we will get that for now… But I hope to find the time in the future to really do that. I’d really like to do that. I’d like to add compression.

In the beginning I didn’t add it because there were concerns by several users with also a crypto background - crypto means cryptography in this case - that adding compression would mean to increase the attack surface that attackers can use. For example, there were several issues with compression in the TLS protocol, which is something different, because it’s an interactive protocol and sometimes they have a man in the middle/person in the middle modifying the packets as they go… This would be a bit different with a repository, but there’s also like – yeah, I can access a repository, the attacker changes something, the next day I access it again… So you have some kind of back and forth.

And the other thing was that at the time I designed the repository format there was no great compression algorithm already baked into the Go standard library, or available as an external library… But this has changed, because there is a person called Klaus Post; he’s working in Copenhagen, and he does all kinds of completely crazy stuff with compression. He’s also a Restic user, by the way, and there’s this issue 21, which is infamous, and I’ve locked it for now, because there’s so much discussion about “Shall we add compression to Restic?” because the answer is obviously yes, but people tend to get distracted by discussing the merits of different compression algorithms. This is the classic bikeshedding problem…

Perry Mitchell: It’s been the biggest learning process of this entire procedure really, just kind of figuring out what motivates me. This has been an amazing teacher in that regard, because until you undertake project anywhere near this size, you don’t really realize what is a superkill joy for you and what actually kind of really gets you up in the morning… And the crypto thing kind of started it off, but you very quickly realize, “Oh, this isn’t so fun. I don’t really wanna come home and do this”, so you work on something else.

James Snell: There’s two things there. With HTTP/1 in Core right now, a number of design decisions were made early on to favor performance over spec compliance. It turns out that there are a number of compliance things in the spec that says “Don’t allow white space in headers”, right? And there’s very good reasons for that, because you get into request smuggling and response splitting, and there’s a lot of real specific security issues that come if you allow invalid characters into an HTTP/1 request. Node was like, “We want things to go fast, so we’re not gonna check this, we’re not gonna check that”, and it was a very deliberate decision not to fully support that HTTP/1 spec. And what we found is that that caused a number of security issues that we have been dealing with over the past year or two years.

With HTTP/2, we’re gonna be taking an approach where we’re gonna be very spec-compliant. We’re not favoring performance over that. We’re not sacrificing one over the other. It is going to be absolutely compliant to the specification, without taking those performance shortcuts. And that is something that I am emphasizing in my own development as I’m going through this, that making sure that we’re hitting all of those “You must do this” or “You must not do this” that are found in that specification. By adhering to the spec as closely as we possibly can, we mitigate a lot of those potential security issues.

[11:47] The other important thing is that even though HTTP/2 does not require TLS - per the spec you can do plain text if you want - the browser implementation’s the primary client of HTTP/2 right now… Chrome, Firefox, Safari and some of the others, they require that they will only talk to HTTP/2 server over TLS. It’s just mandated. They won’t even connect to a plaintext server, so automatically out of the gate you’re using secured connections, and that alone is going to be a significant improvement to security.

The one limiting factor there is Node hasn’t really had a great reputation as a TLS terminator. A lot of people, just as the best practice, put a proxy in front of it, and then they’ll reverse proxy back over a plaintext connection back to Node just to ensure the performance. A lot of that has to do with the way the crypto works with the event loop and OpenSSL and that kind of thing. So I think a lot of work is gonna need to go into trying to improve that if we want to improve the performance of Node as a TLS endpoint and improve on that story.

James Snell: There’s two things there. With HTTP/1 in Core right now, a number of design decisions were made early on to favor performance over spec compliance. It turns out that there are a number of compliance things in the spec that says “Don’t allow white space in headers”, right? And there’s very good reasons for that, because you get into request smuggling and response splitting, and there’s a lot of real specific security issues that come if you allow invalid characters into an HTTP/1 request. Node was like, “We want things to go fast, so we’re not gonna check this, we’re not gonna check that”, and it was a very deliberate decision not to fully support that HTTP/1 spec. And what we found is that that caused a number of security issues that we have been dealing with over the past year or two years.

[11:46] With HTTP/2, we’re gonna be taking an approach where we’re gonna be very spec-compliant. We’re not favoring performance over that. We’re not sacrificing one over the other. It is going to be absolutely compliant to the specification, without taking those performance shortcuts. And that is something that I am emphasizing in my own development as I’m going through this, that making sure that we’re hitting all of those “You must do this” or “You must not do this” that are found in that specification. By adhering to the spec as closely as we possibly can, we mitigate a lot of those potential security issues.

The other important thing is that even though HTTP/2 does not require TLS - per the spec you can do plain text if you want - the browser implementation’s the primary client of HTTP/2 right now… Chrome, Firefox, Safari and some of the others, they require that they will only talk to HTTP/2 server over TLS. It’s just mandated. They won’t even connect to a plaintext server, so automatically out of the gate you’re using secured connections, and that alone is going to be a significant improvement to security.

The one limiting factor there is Node hasn’t really had a great reputation as a TLS terminator. A lot of people, just as the best practice, put a proxy in front of it, and then they’ll reverse proxy back over a plaintext connection back to Node just to ensure the performance. A lot of that has to do with the way the crypto works with the event loop and OpenSSL and that kind of thing. So I think a lot of work is gonna need to go into trying to improve that if we want to improve the performance of Node as a TLS endpoint and improve on that story.

Cory Doctorow: Sure. As I mentioned, I’ve got an eight-year-old and she was born in London in our flat in a pool in the living room. She likes to hear the story of her birth, right? So we would tell her the story of her birth… My wife told her she came and yanked on my arm and shouted, “Story arm”, that I would tell her a story. So she runs up whenever she is bored and she yanks at my arm and yells “Story arm!” And being a writer, I like to iterate when I tell stories, so I’d tell them a little differently every time. I’d start a little further back or go a little bit further forward.

What I realized was that the interesting part of her birth story was the stuff that led up to her birth, and not like the stork stuff, but the stuff about how my wife and I met and became best friends and lovers and a couple, and got married and decided to have a baby. You know, all of that stuff is unique; the stork stuff is the same for everybody. What your parents did to make you is almost certainly something I can guess at with a pretty high degree of accuracy, right? But how your parents came to make the decision to do that and make you - everyone has a different version of that.

[20:08] The open source version of how we got here, we talk about the licenses and we talk about the packages and milestones, but there’s like this really strong social component to how we got here, because around the same time that the open source movement was starting, it was also around the same time that the open web movement was starting, that we were sun setting these proprietary network architectures - whether those were the ones the phone companies ran… You know, AT&T circuit-switched services-centric network or the big commercial services like Compuserve in AOL… They both kick-off around the same time, and yet the open web has collapsed, the open web is almost dead.

We are in a desperate and dire moment for the open web, and the free and open source software movement has soared; everything, including the things that are closing down the open web is built on free and open source software. So that is an amazing thing, and the speech kind of interrogates what the difference is, and how one soared and the other sank, and what we can learn from the free and open source movement to keep the web open as we try to open it up again.

I think the thing that the free and open source software movement had going for it is this thing called the Ulysses Pact. The story of Ulysses goes that Ulysses was gonna sail into siren-infested waters and anyone who heard the song of the sirens would be tempted irresistibly to jump into the sea and the sirens would drown them. So normally, when sailors sailed into the siren sea, they would fill their ears with wax. But Ulysses was a hacker and he wanted to hear what the sirens’ song sounded like, so he had his men lash him to the mast so that he could hear it, but he couldn’t get loose. So what he used was his strong self, the moment at which he was strong, to predict that in a future moment he would be weak and to take countermeasures to prevent himself from giving into that weakness. We use Ulysses pacts all the time - if you go on a diet, you should throw away your Oreos away on night one; not because you’re like incapable of resisting temptation, but because everyone sometimes has moments of weakness, and the strongest thing you can do is to recognize that you will have a moment of weakness in the future and take a countermeasure against it.

In the free and open source world, our Ulysses pact is the irrevocable license, because the failure mode of free and open source software, having founded a free and open source software company, I can tell you is that there are moments in which it feels like your survival turns on being able to close the code that you had opened when you were idealistic. There are moments of desperation when that happens.

Of course, it’s ridiculous, because if you’re making anything substantial under free and open source software, you’re building it on other things that other people have opened and can’t close, and if they were to close off their code your project will collapse. So every one of us wants to be the only one who can revoke a free and open source software license, while all the plumbing that we built on top of stays open. Because the licenses are irrevocable, because you can’t close it once you opened it, you generally don’t even get the pressure from your investors or from potential acquisition suitors or from other parties who can otherwise lean on you and put a gun to your head - they don’t even bother, because there’s no point in shouting at you to close the code, if they know that it’s not course of action that’s even open to you.

[23:44] So even though the same desperation that led us to close the web is present for everyone who’s ever made an open source project that succeeded, that desperation can’t express itself in the same failure mode that the web has had. So my talk is about how we can build a Ulysses pact for a newly opened web around two principles that will keep the web open even in the desperation of its founders, even when the pirates who founded it become admirals.

The first principle is that any time a technology or computer gets an order from its owner that conflicts an order that’s been given to it by a remote party, the owner should 100% of the time without exception win. The owner always gets to overwrite remote policy.

The second one is that any true fact about the security of a system that you rely on should always be legal to disclose, under every circumstance. My pitch is that these two principles should the principles that we become zealots for; that if they’re not calling you an unrealistic idealist about your adherence to these principles, then you’re probably not trying hard enough. So my pitch is that the people who care about building an open web to be the nervous system of the 21st century, to have an Internet of Things that’s not an Internet of things on fire that spy on you and ruin your life, is that we need to like take these principles and cherish them as much as we cherish the core principles of free and open source software, and weave them into our licenses, into our professional codes of conduct, into our membership agreements, into every single piece of what we do, so that there’s never any question that this will come about.

There have been lots of times when the governments have tried to pass laws that say “In order to make software, it has to be closed” and the fact that there’s all of this critical, open software has meant that those laws died every time. Because you’re going back to them and saying, “Well okay, but what you’re talking about is throwing away all the infrastructure on which the digital world is built. What are you planning to replace it with when you pass your dumb law?” You know, reality asserts itself, and so if we can create a reality on the ground to assert itself when governments contemplate stupid laws that say that remote parties can override local parties, whether those are crypto backdoors, or DRM, or lawful interception overrides, or any of the other things that have been the parade of horribles of the 21st-century, then we can make a difference.