The Vergecast - An impossible journey into self-hosting

Episode Date: October 30, 2023

Today on the flagship podcast of network-attached storage: This is the fourth in our four-part series all about connectivity. This week we're talking about software: how software connects us, how we connect to software, and how software connects to other software. Email us at [e-mail] or call us at 866-VERGE11, we love hearing from you. Learn more about your ad choices. Visit podcastchoices.com/adchoices

Support for the show comes from Retool. Too many companies run critical operations on duct taped spreadsheets, Slack workflows, and whatever else they could cobble together. Not because they want to, but because building internal tools means weeks of waiting on someone else's backlog. That's where Retool comes in. Build custom internal tools just by describing what you need. Prompts something like,

Build Me a Revenue Dashboard on our Salesforce data. And Retool actually builds it on your company's data, in your cloud with enterprise security built in. Go to retool.com slash vergecast. We all need to retool how we build software. Welcome to the Vergecast, the flagship podcast of network attached storage. I'm your friend David Pierce, and this is the fourth in our four-part series all about connectivity. Over the last few weeks, we've dug into the ways we connect to content, to each other, and to audiences.

And this week, I want to talk about something a little different. I want to talk about software. How software connects us, how we connect to software, and how software connects to other software. And that story, at least for our purposes today, starts with the computer I bought a little while ago. I bought it on Amazon with essentially no research, but I bought it. It's called the B-Link Mini PC. It has 12th generation Intel chips, 16 gigs of RAM, 500 gigs of SSD storage to find a little computer. And it's just this little box of a thing about the size of like two of the boxes the iPhone comes in. It's pretty small. And I just,

hit it immediately off in the corner of my desk. I bought this thing because I wanted to test a theory. That theory is that maybe self-hosting is the future of technology. Over the last two decades, really, we've been on this race toward cloud software, in which all of the apps and platforms and data you use are stored not on your computer, but on a server somewhere in a Google or Amazon or Microsoft warehouse. There are a lot of good reasons for that shift. There are a lot of good things about cloud software. And there are also a lot of reasons to think cloud software is not going anywhere anytime soon. Here is Peter Van Hardenberg, who works at a research lab called Inken Switch, explaining the upsides, I think, pretty well. The idea of the cloud was that,

hey, it turns out that actually shipping software onto people's computers is a huge pain in the neck. It's out of date. You can't fix it. If it breaks, you have no idea what's happening. There's all these problems. And I think the biggest thing just from like a brass test, tax perspective. It was not a technical problem. It was like an onboarding problem. Cloud software gets users easier. We're going to come back to Peter in a minute, I promise. But cloud software, for all the things it makes easier and more useful, also has lots of downsides. It doesn't work offline, for one thing, because it's not really on your device at all. Also, if that software's developer goes away or pivots to something else or just decides not to deal with you anymore,

the software you rely on can just disappear. The cloud software, is convenient and great, but it's just fragile, and it is so fundamentally not yours. So like I said, I had this theory that self-hosting might be the answer. At least for important stuff, I figured maybe I should stop relying on cloud services and instead build a system that lets me access my own stuff from anywhere through tools that I control. So I bought this B-link and started setting stuff up. It went poorly.

The main thing I discovered is that self-hosting is hard. I'm not the world's most technically capable person, but I know my way around a computer, and still I could barely get things up and running. If you want to set up a Plex server so you can get it your movie collection from anywhere, that's pretty easy. But at least in my experience so far, there's essentially nothing else out there that is that easy. One great guide I found is from an author and entrepreneur named Derek Sivers, who created a really handy step-by-step system for registering a domain,

setting up your own cloud storage and routing everything from files to email to your calendar, all to that system. He calls this guy Tech Independence, which I really like. And it is really useful. You can get through it without knowing a ton going in. But it is so much work. And it requires a lot of technical sophistication just in the sense of you have to know what terminal is and how to open it and what to type in and just time and energy.

It's just a lot. I won't lie to you, I bailed about halfway through the process. I ran into a thing with the FTP server and just gave up. One tool I did manage to set up is called Image. It's a self-hosted alternative to Google Photos. I was thinking about it at the beginning of this process and realized that if all my cloud stuff were to disappear tomorrow, the photos I lost would be the worst part.

So I wanted to switch them over to something that wouldn't go away. And Image is actually a great tool. It has a nice mobile app. It has lots of features. It's a pretty passable Google Photos replacement. But by the time I downloaded Docker and was worrying about virtual machines and containers, it was eating all the memory on my computer, I was just back to feeling totally over my head. I did eventually get it working, but I can't imagine most people are going to want to do all of that work.

Image was created by this guy named Alex Tran, and I kept wondering how he felt about the setup process. So I called him up and asked him. He told me that he started working on Image in the first place because his wife wanted a tool like Google Photos, but didn't want to pay for Google Photos, which as far as I'm concerned is like an extremely universal opinion on the internet. So he set out to build something that was self-hosted and easy, and he found nothing. So when I first started Image,

I used Image as the opportunity for me to learn about, you know, how to build nice software, how to build good software. So I structured it in a way of using Docker. Using Docker is actually coming from the idea from the community on the self-hosted subrediting. that everything should be running from Docker because of the ease of development and maintenance. At the time, I didn't have a lot of experience with Docker, so it's nice. It's perfect for me to learn how to build a Docker image, how to put that into a deployable way.

So I put everything into Docker Compose. And at first, there were a bunch of settings that you have to do before running the Docker Compose Upcom command to bring up the whole application. And over time, that has been simplified, and now we basically move all of the, anything that you can configure through the command, through the environment variable. Now you can do it directly inside image. So it's cut down that initial configuration to the point now that the only thing that you need to change when you're setting up a new image server is the location where you want

to sort a file. And then you just do do Docco Compose up. it would run. Yeah, I found the install package on your website even, which was surprisingly simple. I was impressed with how quickly I got up and running. Yeah, it has gone through a lot of improvement. And for sure, this is coming from the team that has experience with a lot of deployment. So I'm really thankful for them to help me learn. Yeah, that's awesome. But do you think just the fact that it requires Docker kind of immediately rules out most people. Like, I don't think I'm going to convince my wife to, like, even know what Docker is

in order to set up a photo server, right? Is that just kind of the cost of doing software this way? Like, is there a world in which all of this can be made simpler and easier over time and start to feel like, you know, you can install and set up a server just, like, installing and setting up another app? Yeah, there are a lot of requests for that. But from my point of view, when you are doing something, especially for self-hosting, right, and now when it comes to your really important data, like photo, the person who managed the server

should have some technical knowledge about managing the server. I think it is something that a self-hosting person should learn is to how to use Docker, because now when you go into the awesome self-hosted GitHub repository, most of the application you see can be run from Docker because it's just made the development easier, more mainstream, and also the deployment easier and more mainstream. For example, you can deploy it on Debian, Ubuntu, or Fedora, the same way, without worry about which package should be,

compatible with my distro or with this version. Everything is just work from the containerization standpoint. What's your sense of kind of the state of the self-hosting movement in general? Now that you're in it now, you've been talking to people. I feel like there's been this little crowd of people who really believe in self-hosting, and they're mostly very technical, and they understand how to make it work, and they know all of the different sort of underlying systems, and they spend a lot of time in terminal.

But I don't feel like the self-hosting world has ever quite gotten out of that. But part of me thinks it might be starting to happen. Being able to kind of have your stuff on your device but access it from anywhere is starting to be a slightly more mainstream thing. What are you seeing? Do you think self-hosting is about to hit the big time? The recent sentiment is that a lot more people are starting to concern more about their privacy with all the story about the third party. or the services that you use can access your data. So more and more people are starting to be noticing that.

And I think the more people are starting noticing that, then they will start to find a way to get back that control of the data. And it would be a good drive to get people to look into self-hosting more. But of course, this is a very technical feel, right? you would need to have some IT knowledge, some computer knowledge, as well as networking, etc. So that's why it's not that easy for other people to get into, but someone to really be interested in this. So I still feel like there's maybe a long way to go in order to get more and more people to get into self-hosting. But with the trend of, you know, high paying CS degree, high-paying,

CS job, so more people get into computer science. So it's exposed them more to these things. Yeah, it's going to be interesting to see if the trend is that more people gain these skills, or if that these tools and systems become simpler. And it'll probably be a little of both, right? Like, do you think there is a path for, you know, the people who just don't have the interest or expertise to care about Docker to maybe in a few years be able to make use of a tool like this? It seems like we're kind of one really great user interface invention away from this stuff being easier. Do you think there's a way to get there? Yeah, we're always looking for the way to make it simpler.

But as up right now, I think with the limitation of the tool that we have and the tool that we have access to, in order to serve to fulfill the purpose of high performance, easy to maintain, right now I don't see a tool better than Docker, unless we have some invention down the road in this space that compete with Docker and to make things even more streamlined and easier, that would be really cool thing to have. But as up right now, I don't see the alternative. If you do know anything, please let me know.

By the time I'd finish talking to Alex, I'd sort of given up on the idea that self-hosting can be a mainstream solution for people who want more ownership and control of their stuff. Seriously, just the fact that Docker, an app that's all about containerized application development might become a mainstream thing that people know how to use, just seems wrong to me. I just don't think that's going to happen. I don't think it's necessarily impossible to make self-hosted systems that are user-friendly and simple.

I think Plex is actually a really good example of how to do it right, but there's just not much else out there that qualifies right now. But as I was asking around, trying to figure out what might work if self-hosting doesn't, I heard about this concept that a few people mentioned to me. It's called Local First Software. And when we come back from a quick break, we're going to talk about why Local First Software might just be the best of both worlds. We'll be right back.

Support for this show comes from Shopify. Starting something new isn't just hard. It can be really scary, too. So much work goes into this thing that you're not entirely sure will even work. But here's a better thought. What if it did all work? What if your instincts were actually right all along? Shopify wants to help you get there.

They're the commerce platform behind millions of businesses worldwide and nearly 10% of all e-commerce in the U.S., from established brands like Allbirds and Heinz, to companies just getting started. Their design tools make it simple to create the exact online presence you're envisioning with hundreds of ready-to-use templates available. And with built-in marketing tools, you can launch full email and social campaigns in just a few clicks.

So you can connect with customers wherever they are. It's time to turn those what-ifs into with Shopify today. You can sign up for your $1 per month trial today at Shopify.com slash vergecast. You can go to shopify.com slash vergecast. That's Shopify.com slash vergecast. All right, we're back. Okay, local first software. Let's go back 40 years or so to the early days of the computer era.

Computers were huge in boxes and beige and made by a bunch of companies that, mostly don't exist anymore. Back then, cloud services weren't a thing. Nobody was running all their software on servers anywhere because none of that existed. People acquired software by like going to a store and buying a box that had a disc of some kind in it that you plugged into your computer to install a program. That all sounds sort of quaint now. Like can you imagine getting in the car and driving to Target every time you wanted to get a new app on your phone? Hard pass. It's all much better now. But that approach did have one really nice side effect. Your software was yours. It was installed on your computer locally. If the company that made your game went out

of business, you might not get updates, but your game would still run fine on your computer. If the developer of your productivity app made some horrible UI change you hate, no problem. Just don't buy the next version. That's how software worked for a long, long time. One way to think about it is that our computers used to be the home for our software, and now they're just the way that we access software that lives somewhere else. That difference feels. small, but it actually totally changes the way we think about what our devices actually do. Which brings us back to Peter from before. Remember the cloud services guy from Inkin Switch? He is a big believer and promoter of the idea of Local First Software, which he thinks can

combine the best of all of the last four decades of software. Basically, in a local first world, your apps live on your device. Just like they did 40 years ago, they are yours, your software belongs to you. And you can access them offline or without worrying that they'll still be around tomorrow. But you can also connect that software to the cloud and get all of the collaboration and multi-device sync and in general the convenience benefits of having it in the cloud. This sounds like the best of both worlds, right? This is how it should all work, I think. So I called it Peter to ask him how it works, why he's such a big believer in the idea, and why software didn't turn out that way in the first place. He started by telling me a story about a music app that I certainly

had not thought about in a long time, and I bet you haven't either. It's called Ardeo. Ardeo was a great piece of software, but the offline mode for the Ardio app was like a whole other program from the main app. It had different features. It behaved in different ways. It had different bugs. And I just remember this feeling of like, why was the song I just listened to and the playlist I was just looking at? Where did they go when I went into offline mode? Because I had them here.

And so in a sense, what was happening is that this app was deleting my data. Right. And like there's a more sophisticated, like I'm a developer. These are my friends who built this app. I've worked on this stuff. I know the real answer is more complicated, which is that like, you know, the kind of normal way of building apps in this era is that you have a server, which is where the software really lives. And the thing that you hold on your in your hand or the thing that you have on your computer in front of you, that's not really the program. That's just like a mask in front of the program.

And it talks to the program on your behalf. And it presents like a pretend version of the program that's what you use. And I had this feeling of like, especially though, if you have an offline mode, then you need to have the program because you can't talk to the program when there's no internet. Right. But it's crazy because everybody's building like this sophisticated program. They're running it in the cloud. And then on the mobile app in the device for offline mode, they run smaller, worse versions of it that don't actually work the same way. And I was just like, how about this?

How about we write the program? We run it on our computers. And then we talk to the cloud to get the data. And then we have the data in our computers, whether they're on. our pockets or on our laptops or whatever because like when you go in an airplane or in a taxi or take muni and your computer just turns into a paperweight that sucks and not only that but like I was a huge fan of RDO I know a lot of people who loved RDO you can't use it anymore right you can't use it anymore because you never had it I can still run Winnamp I can go and download Winnamp

and I can run Wynamp today I can find all those sweet skins from the 1990s I can use Winnamp But RDO is gone forever. And as I got deeper into this stuff, the more I started to think about that, and the more I realized that, like, not only is this just an inconvenience for me, it's a disappointment, right? Like RIP, Google Reader or whatever your favorite cloud software that's gone. But like, we're in a dark age of software. And I mean that not in like the sense that the software is bad.

What I mean is that every piece of software that runs today that's built the way we build software, everything we built on Heroku, where we used to, you know, to work, all that stuff is going to disappear irrevocably soon. And everything that we've built and everything that we've done in this era, all of our collective communal work will be lost. The thing you're describing, though, where it sort of matches the best of those two things, this idea of local first software, how did we not get to that sooner? That seems like anyone sort of looking at this for a long time should have thought, what if I had the app on my device? Like, Like, Ardeo is such an interesting example, right?

Like, the people at Ardeo, did they just not think someday this will all be gone? Wouldn't it be nice? Like, this is one of the things I go back and forth with all this software is, I understand all the reasons it's easier to build Cloud First software and that it's more, you make more money doing it. That all makes sense. But part of me wonders, like, is the reason just that people don't care about the flip side? I don't think that's it.

I think there are a few elements here, but a lot of it comes, there's two things. There's a technical challenge and there's a narrative dimension. Okay. The narrative dimension is that, you know, everybody wants to build the next big startup and make a billion dollars. Venture capitalists are telling everybody that's how to build software. Everybody thinks that they have to build for Google scale. They're going to need Cassandra. They're going to have a billion users.

They're going to be, you know, it's the thing's the rocket ship, you know, just hop on. And like, when you approach building software with this mindset, then you reach for the tools that other people who have done this task have used. And so a big part of it as well is that, like, you know, there's like the term is path dependence, right? Like, we started making cloud software and we're like, oh, this is great. And then we just kept piling more and more energy onto that, trying to solve the problems of it. And there was very little investment on this other axis. You know, there was like the offline first movement, which I think, you know, is a closely related precursor. But like, the narrative has been like, well, why do you want that? The cloud solves all our

problems, right? Like, internet is everywhere. You've got Wi-Fi at home. You've got Wi-Fi. You make a hotspot with your phone. Everyone's got internet all the time. What's the big deal? Just wait. It'll be there. And so, first, that's not true. I mean, there is internet more and more places. But the other thing is this kind of like the consequences of the cloud took a long time to become clear. Right? When we started working on Heroku, you know, and back in the day, there wasn't killed by Google.com. We didn't have a history of apps that had come and gone. And now we were lost because we hadn't had time to go through that sort of generational cycle. So I think a lot of the problems have, you know, as so often is the case that emerged over time, right? If you look at the

oil era, nobody was like, hey, this awesome energy source might turn out to have some consequences someday. People like, this is amazing. I can go see my aunts and I don't have to like feed a horse to get there. That's very fair. And it does seem like, you know, you mentioned the narrative side and the technological side. And it does seem like with sort of the, I don't know, manifesto of local first software, You did try to get at both of those. Because I think one of the questions I came into this with was, like, to what extent is the kind of heady case for data ownership and longevity and the idea of, like, having a space on the internet that's mine?

How far does that really get you? And I feel like you do make some of that case. And I'm curious how broadly effective you think that case can be. But then there is also, like, at some point, you just have to build better products. And I feel like one thing I liked about the way you guys approached it is you also make the case that this is a way to make better products? Yeah, I think these kinds of philosophical perspectives will motivate a certain audience, but I think that when you make the right thing, the easy thing, people will do it. It's as simple as that. If it's cheaper and easier to build

software local first, then people will do it. And so what we do is we just focus on that problem, which is, you know, we care about some of these things, and we know there are people who care about some of these things, and that's great. And there are people with privacy concerns, like activists and so on. But like, I think when you look at those narrow niche markets, those audiences, they're great people with real problems. And it's great to be able to help people who have those problems. But like, we all want software that works. We all hate when the thing doesn't go, when the keystrokes are too slow when you hit submit and you get a spinner. And if we can just make it easier to build software in a way where that just doesn't happen or happens

less than I think everybody will be happy. So just make the right thing, the easy thing. You were saying, oh, earlier, like, is it harder to build software this way? It's impossible to build software the way we build software. It costs a fortune to build software the way we build software. You need to learn Kubernetes. There's literally like 200 three-letter acronym services that constitute Amazon Web Services. And then on top of that, you have to learn go multi-cloud and learn how to do it on Google and Microsoft as well. It's impossible to build software today, the way we build software. It's like you want to go to the grocery store and you've got to use all the technology to build an aircraft carrier to get there. What we need is bicycles, right?

But all we're building is aircraft carriers. And this is like the Jonathan Edwards line, right? We were promised bicycles for the mine, but we got aircraft carriers instead. It's so complicated to build anything in the cloud. And then on top of that, once you do, you figure out your GraphQL and you're, you know, whether you use Postgres or Mongo and like what front end framework and node or go on the back end and do you need to use OTH Zero? Do you need to use this?

Like all these cloud services, you put it all together. You get the damn thing running. And now you've got to pay every month to keep the thing online. And when anything falls over, you get paged in the middle of the night, woken up. It's impossible to build software. And if you do, you're going to regret it because it's going to cost you a fortune and wake you up. Yeah. And most of the pieces of that equation, you have absolutely no control over.

Like, I'm reminded of this every time AWS goes down. And it's like, oh, the internet dies whenever AWS has an issue. Like fundamentally, we rely on Amazon to keep its data centers up to, like, live our lives. And that's bonkers. Yeah. And also hilarious is just that, like, we've so totally broken the internet as this, like, mesh network that literally, if you and I were in the same room recording this call, all of our data would probably be bouncing off of U.S. East 1 in Ashburn, Virginia. and back to each other's laptops just so that we could collaborate.

It's wild. I think there's a bunch of other interesting problems. I mean, like, there's interesting challenges around, like, you know, the networking stuff, right? It's called a browser, not a keeper. All this app that I'm looking at right now as we're talking, when I close and open the tab, it's not going to be saved. I can't come back to this work. And the browser really assumes that you're just kind of grazing as you use your computer. But it's become the main platform for software.

And so then there's Electron, which is like a wrapper around a browser with a bunch of bells and whistles. But like all this stuff feels kind of unsatisfying. I think, you know, it's tough when like the incentives of the organization that builds the most important piece of software on your computer are to sell you ads. Like the platform we all live every day in is run by an ad company. And, you know, lots of great people at Google, they care about these problems. But like, there's just an incentive structure here that's not favorable for. solving these problems. Yeah. And so there's some of that dimension. But I think in terms of like value and priority, I think one thing that we are really interested in at Inc and Switch is

what we call malleable software after Philip Chernowski's PhD. And this is this idea that, like we live in this weird world where like computers again are meant to be this like very powerful, compositional, informational environment. But increasingly like all of the software we use are these like closed boxes that are given to you by somebody else and you can't do anything with, you know? And so I like to think of the ideal computing environment as being like a wood shop or a kitchen. Like in my kitchen, I can make Indian food or Japanese food. I can go and like reheat some leftovers. And like I have not too many kitchen gadgets, but like you can go a long way with a chef's knife and a cutting board and like, you know, a stand mixer. Yeah. You know, it's a measuring spoons. Like you can do

a lot with like a few good elements. But like the software world is very much like, you know, oh, this note taking that, you can't open the notes from that, you know, taking that. And so I think a lot about like once we have local first software, for us, this is really just the first step, right? If the software is local first and you have the software, then just like if you bring shelving home from IKEA, you know, you can decide whether or not you want to put all the shelves in or if you want to set it up on its side or upright. If you want to cut the legs off the chairs because you're short, you know, you want to paint it a different color to make. You know, you want to paint it to different color to match your space, we're really interested in this problem of like,

once we have the software, can we start to actually use it? Can we make it our own? As we see the local first movement start to build steam, we see so many people getting involved. Our vision is starting to look forward to like the next frontier, which is actually empowering users to not have to care about these things, but to be able to care about these things. right and in your home if you have a challenge you might go to the hardware store and buy the things and fix it for yourself or you might hire a handyman or maybe you live in an apartment and you call your super sure right but whatever that relationship you have to that space is it's something that you can have agency and make choices about and we think that all computing environments should have those properties and we want to start figuring out how to bring that next to the broader world and that's kind of where we think about where this goes after we start to see local first software take off This is all kind of heady, I know. But the app that I was thinking about that helped me understand the idea is this note-taking app called Obsidian. You might have used it.

It's pretty popular. It's a great app. Big fan. Obsidian is above all, just an app you download to your computer that reads and writes text files. If you boil it all the way down, that's what it is. The company offers a service for syncing your files, but that's a separate thing. And if Obsidian goes out of business, you can always sync through Google Drive or Dropbox or lots of other things. and Obsidian is built on a plug-in system,

so the main app is really basic, but you can add all kinds of functionality just by downloading a bit of code or even writing some yourself. If Obsidian ever goes away, you'll still have the app. If a plug-in ever disappears, you'll still have the version that you installed.

And if for some reason way down the road the app ever stops working entirely, you'll still have your folder of text files because that's all it is anyway, and you can just take them somewhere else. Obsidian, the company, is building new tools for sharing and publishing, and lots of other stuff, because, again, the cloud is a good thing.

There are lots of upsides, but you don't have to use any of them. And if obsidian goes away, you'll still have obsidian. That is local first software right there. I love it. All right, we have to take one more break, and then we have one more big idea about software to talk about. We'll be right back. Support for the show comes from Grammarly. You don't need reminding that the world moves fast.

But work today requires clear communication, and when every message counts, sounding rushed or generic, can be getting lost in the shop. Rammaly gives you one place to think, write, and finish your work where you already write, while giving you access to agents that help you sound natural and engaging. No matter what kind of writing you're doing, Gramerly helps you get ideas done faster and move from draft to done with less friction. You can use Gramerly's AI chat to brainstorm ideas, outline a solid draft, then refine it with context-aware suggestions that fit what you're working on.

See why 90% of professionals say Grammarly has saved them time writing and editing their work. In a world of generic AI, you don't have to sound like everyone else. With Grammarly, you never will. Download Grammarly for free at Grammarly.com. That's Grammarly.com. All right, we're back. As I was working on this episode and trying to figure out what it means to take back some control of our software and our devices, I was also reading a new book called The Internet Con by Corey Doctoro.

If you've never heard of Corey, he's an activist and author and blogger, and he's been thinking about the way that the internet should work for a really long time. And this book is basically a step-by-step guide for how to take down the tech giants. He argues, as he often does, that the internet is run by a few huge companies. That's a problem, and we should stop it. Most of that is a conversation for another day. And I don't agree with all of Corey's thoughts on the subject, but it's a really good book. It's really interesting and worth reading. The thing that jumped out at me most about it was Corey's specific idea for how to improve our tech situation. He doesn't argue for breaking up the tech giants or reinventing capitalism altogether, though I suspect he'd be cool with both of those things. He actually makes the case that interoperability, different apps and platforms being compatible with one another, is pretty close to a one-stop fix for everything. Ever since I read the book, I haven't been able to stop thinking about that idea, that maybe instead of,

going back to having all my data only on my device or only using software that works offline, the solution is just to make it so easy to move between services that a few of them going away wouldn't make a difference. I guess like if the whole internet goes down, you're still in trouble, but we're in big trouble anyway if the internet goes down. Anyway, I wanted to understand why Corey thought interop was the answer, like the answer. So I called him up to figure it out. The biggest picture thing you talk about is interoperability and the idea that what we should do is by hook or by crook, open all these platforms to each other and to others. And then I think if I'm not misunderstanding this, web standards are the fastest way to get there,

right? Like I feel like I've spent the last year or so talking to people and betting on the idea that like the open web can be the solution to a lot of our platform problems. If only we allowed it to be, you're making a face. Tell me what you think. So I would say it's not quite web standards are how we get there because first of all, web standards are mandatory. So we've all versions of embrace and extend. So I would say that there has to be a two-pronged approach. One is rules about what you must do. So we might say to Facebook, you have to open up a gateway. And that might be through legislation, but it might be through a settlement, right? Like Facebook and Twitter and all these other companies, they're just incapable of coloring within the lines.

They're just like pathological cheaters. And so they're all already under multiple FTC consent decrees and European Commission consent decrees and whatever. And they're all violating them. are all eventually going to be dragged into a situation where they're going to seek a settlement. And so we might as a settlement say, oh, you have to stand up these gateways. But like in theory, the EU's legislation about interoperability between messaging apps, that's the kind of thing you're talking about. Yeah. And the Digital Markets Act, it's not just messaging apps.

It's a whole bunch of different platforms. They're just starting with messaging, which we can talk about this later, I think, is a mistake. They should be starting with social media messaging if they screw it up is going to, like, expose dissidents and other people to leaks in their messaging. And it's like the next Jamal Khashoggi who's murdered the way Jamal Khashoggi was by someone exploiting a defect in the instant messaging tools that he uses to lure him to his death is going to discredit this whole project. It's a huge mistake. But it's not just those mandates, right? Like, because that's going to roll out over 10 years. In parallel, there's like Facebook violating its consent decree. Google just violating its consent

to create Twitter violating all of these other rules, you know. And they're going to, in parallel with this, someone might just say like, okay, well, if you want to not be fined 10x your market cap and live to fight another day, you're going to have to consent to standing up this interoperable gateway. Twitter is going to have to offer an activity pub gateway or something, right? And the problem with that is it's very hard to administer that remedy. And we're getting into some wonky sort of public administration stuff here. But like, say we say to Facebook, you have to stand up a gateway to activity pub so people can leave, go to a Mastodon server, but still be connected to the people that matter to them and the

customers and the communities and all the things that they are sort of glued to Facebook by. But then Facebook shuts down that gateway and says, we shut it down because we thought there was another Cambridge Analytica that was stealing a billion users data, which is a thing that actual future Cambridge Analyticas are going to try to do, right? They're going to try to exploit this APO. We just saw, you know, 23 and me get scraped for however many million Ashkenazi's genetic records and just like as an Ashkenazi person, a very creepy sentence to say, you know. And so we're going to want them to like have an intrusion detection system in a firewall and

security engineers. But how do you distinguish the pretext from the reality, right? When Facebook says, oh, we're shutting this down once a week because we're worried about vans and active attacks, when everybody who understands Facebook's infrastructure is to a first approximation of Facebook employee and you're like deposing these people and spending like years arguing about whether this was a pretext or not. In the meantime, the new market entrance, these Macedon servers or whatever it is that have stood up to like welcome in Facebook refugees that were evacuating from Facebook, those users are learning that they can't rely on them. The financiers,

the banks or the individuals who funded them are learning that you shouldn't fund these projects. And the people who started them are learning that it's not a fruitful thing to do with their time. It's a waste of their time. So you also need to re-legalize the stuff that Facebook did to MySpace. So when Facebook started, everybody was a MySpace user. And they didn't just say, hey, come hang out on Facebook. We have a better user interface. Eventually your friends might show up.

And in the meantime, you could admire our great color choices. They said, like, here's a bot. Give it your login. Give it your password. It'll go to MySpace several times a day, impersonate you, log in, scrape your inbox, put it in your Facebook inbox, It let you autopilot your responses back out to Facebook. So you, to MySpace.

So you can eat your cake and have it too. So what if we re-legalize that conduct? Because, you know, when people try to do that to Facebook, like Power Ventures did or OG app or other tools that have popped up to do this to Facebook, Facebook just sues them into like radioactive rubble, right? Computer fraud and abuse act, DMC, 1201, tortious interference with contract, patent, trademark, copyright, all these other kind of this thicket of what we call IP, but which is like the right to control the conduct of your customers, critics, and competitors.

And so, you know, if we re-legalize that conduct, then those new market entrance who Facebook locks out of their API could fall back to scraping bots, reverse engineering, and other tools. Now, that's guerrilla warfare with Facebook. In general, I think Facebook will lose that over the long run because for Facebook to successfully defend this, they need to make zero mistakes and to successfully attack their defenses, you need to find one mistake. And so that will privilege them. But I also think Facebook would all other things being equal prefer a managed solution where the API is reliable to a situation where they cannot use the law to stop these adversarial interoperators because guerrilla warfare represents an

unquantifiable risk to Facebook. And shareholders do not like surprises. And we saw Facebook lose a quarter of a trillion dollars after their first report of 2022 to their shareholders when they revealed that they, it wasn't even contraction, it was less growth than they'd anticipated among U.S. users. And the people who bore the brunt of that stock crash were the managers who made the decisions that led to the reduction in users, right? Because they're the ones whose portfolios are primarily stuffed with Facebook stock, right, more than anyone else.

They're the least diverse shareholders, right? And so if we say to Facebook, to the decision makers at Facebook, if you break your API, you will have to contend with guerrilla warfare. And that guerrilla warfare will produce the surprises that will make you personally significantly poorer. Then I think we align their incentives. But of course, no one ever lost money by betting on the hubris of tech executives. So if they do go ahead and do this, then we have a fallback. That's what I mean by like an administrable remedy, right? an actual plan that looks at what Facebook is doing that harms people, what stops people from

getting out of harm's way, what will moderate those harms, and what we'll do when Facebook takes a countermeasure to recover its supernormal profits at the expense of everyday users and how we will counter that. One, like, much lower stakes thing you're making me think about is, like, I'm an obsessive user of note-taking apps, and I switch between them constantly. Are you an Evernote casualty? Oh, yes. And this is kind of, this is actually where I was going, is one of the first.

things you do if you build a note-taking app is you build an Evernote importer because there are a lot of people who have hated Evernote because it's been very bad for 10 years who are stuck there because they have thousands of notes and they want to leave and Evernote makes you export in this like dot E-N-E-X file that is proprietary but also everyone else has figured out how to manage it and so I can now with two clicks pull all of my Evernote notes into some other app which has made it possible to leave Evernote for tons and tons of people who otherwise would not have been allowed out. And what it is in social is like I'm stuck in Evernote for the rest of my life because it is so hard to switch that I will put up with whatever nonsense there is just to be here. And like the note taking is such a smaller version of it, but is like that's how it should work. That's a great example because one of the reasons that that's true is that Evernote started late or started early. If Evernote it started later when they were when they were better developed, more reliable and more widely understood strategies for blocking that reverse engineering. you know, if they were encrypting those databases, then bypassing the encryption would be unlawful. If you could only access those databases through an app that blocked scraping and autopiloting, then they could use terms of service violations to stop you from running something locally that just iterated through every note you had and then spit it out, right?

So like, it shows you that while mandates are important, right, we could, if Evernote were large enough and enough of a hazard, you could imagine a future in which Evernote was legally. required to offer you an export tool. But you don't actually need it some of the time. Some of the time rival firms can just work this out. And that's what Apple did with Microsoft Office. You know, I tell this during the book, I was a freelance CIO running, you know, networks for all these small and medium companies. And a typical company would have 20 people with Windows PCs and a designer with a Mac. And if you tried to send that designer a Word file, an Excel file, an office file and they tried to open into my Mac office, it would either not work or then after they made changes and saved it, it would be corrupt or, you know, some variation. All you had to do

is like wave the Mac office floppy around and files would spontaneously corrupt. And I just started like, first I put PCs on those designers desks that they used as dedicated office workstations. And then when that became unwieldy, I put big graphics cards in their PCs and got them Quark and Adobe for their PC and threw away their Mac. And Apple figured out this was happening. And so they just got engineers to reverse engineer office. And so we get iWorkSuite, pages, numbers, and keynote that reads and writes the Microsoft Office files. And then the really interesting thing is what Microsoft did, because after a few rounds of aggressively changing those file formats and incurring their own engineering expenses, because then they have to update all their own Windows software, they sued for peace. And they standardized the office file formats, which is why we have the X at the end of the XLSX and PPPTX.

and Doc X, which stands for XML. And this is why you can now paste-style text between Word, Google Docs, Webforms. You know, Medium has a parser for it, right? Like if you're composing on Medium, I bet your CMS does. I know the Verge has got its own CMS that you guys built from scratch, but you probably just imported a like a reference library for parsing out those things so you can compose in Word or docs and it just works. Yep.

And so like at a certain point, when you have to use engineers, to block interoperability instead of lawyers, then you just give up. Because lawyers solve the problem forever, right? Lawyers teach every financier, every entrepreneur, and every user. Don't trust interoperable solutions. Engineers, they have to fight and fight and fight, and eventually they lose in these wars of attrition. And so once you take away the lawyers, the company sue for peace.

At least as far as I can tell, like Mastodon and sort of what the whole activity Pub world represents is like the closest extant thing to the kind of interoperability that you're talking about. Yeah. And Activity Pub came out of the W3C at the same time as all this bad standardization was happening. And the reason that this good standard emerged without being interfered with, I think, is that the big tech companies didn't believe it would matter enough to sabotage it. It wasn't like they couldn't.

It's just that they chose not to. And they could have submarineed all kinds of proprietary. advantages and so on into it. And they just didn't. And as a result, we got this thing that just kind of snuck in under the radar because no one thought it was important. It's a bit like what happened with the web itself, right, where like nobody took the web seriously enough. When the web came along, the fight was between AOL and CompuServe. And just like nobody took it seriously enough so Tim Bernersley was able to make a thing that Microsoft didn't extinguish the way they were going after rival online services. And then by the time the web took off,

enough, they tried afterwards, right? It became a success and Microsoft tried all these variations. You know, if you remember, there was a time when MSN meant something new every six months, because they would relaunch MSN as some proprietary thing that was like the web, but not the web. It was Blackbird at one time. All this stuff were they were just trying to lure people into locking into a proprietary technology stack to extinguish the web. And like it just snuck in under the radar. Nobody was paying attention to it. And then all of a sudden it was there. And it was like too big to kill. And, you know, I think that activity pub kind of fits that, that window. It just snuck in when no one was looking. What do you make of the fact that like Adam Masseri is

constantly saying that threads, which is not currently federated very much a closed platform, is going to be part of it? Like, is that a, is that a company sea change? Or is that just a guy saying the right thing at the right moment? Well, I think that even people of goodwill can talk themselves into doing bad things. Like, let's stipulate that Messary is completely sincere, right? But in two years, there's 400 million daily users of threads and they just rationalize that opening those users up to Federation would expose them to risks that Facebook is currently able to defend them from, that they have the, you know, moderation tools and the

other things that are needed to prevent disinformation and so on. And that federating will expose new risks to those users. And it's just unfair to those users. Which to some extent is not untrue. Sure. Particularly if you have a bunch of users who become accustomed to certain practices that don't take account of the risks, but also the benefits of federation. And so you just drop them into the deep end. And so the way that you protect your future weak self is for your present day strong self to do something that is irrevocable in that service.

So like we call these Ulysses Pacts, right? Ulysses in the tail, he's a hacker. He doesn't want to fill his ears with wax when they sail through the sea of the sirens to prevent their calls from luring him to his death in the sea. He wants to hear them. So in this moment of strength before he's hearing the sirens call, he has a sailors lash him to the mast and says, whatever I do, don't untie me so that I can live through this. I can experience the benefits of my strength even in a moment of weakness.

And we've all done versions of this, right? You throw away the Oreos the night you go on a diet, right? that's a form of Ulysses pact. Open source licenses are a form of Ulysses packed because they're all irrevocable, right? Every time an IP lawyer who isn't familiar with open source first encounters an open or a free license like the GPL or even the BSD license or whatever, they go like, oh, this is, this is dumb. Everyone must have missed this. This should have a way for you to revoke the license later if you change your mind. And that is not a bug.

It's a feature because when your investors come to you and say, well, this is. was cute, but if you want the 150 people you convinced to quit their jobs and put their kids' college funds on the line to come work for you, to have a job next week, you're going to make this open source proprietary next week. And you can just say, like, you're the boss, but I can't. Like, I just can't. And so for Facebook to say, well, someday this will be open, trust us, given the company's track record is bananas, right? Because Facebook in 2006, their pitch to MySpace users was like, you love your friends, but did you know that the evil, crapulent Australian billionaire who owns Myspace, Rupert Murdoch spies on you with every

hour that God sends? Facebook is the service that will never spy on you. That was their pitch in 2006, right? We're the surveillance-free social media platform, and we always will be. And in 2008, they pulled their users and said, we're going to start spying on you. Is this okay with you? And they said, no. And they did it anyway, right?

So like, as George Bush taught us, right, fool me once, shame on me, fool me twice, we don't get fooled again. Right. And, and you know what would be a more compelling thing than promising to federate? Federating, right? And if they're not federated, then all it is is a latent capability. And like, computers are touring complete universal von Neumann machines. So every capability is latent in every service, right? Like, unless there's some means by which users can discipline executives who take back. add choices, then we should expect those executives to fall prey to the same folly and rationalization that all of us are capable of. Yeah.

And I think it sounds like you're of the mind of there are sort of two approaches. One is to essentially mandate that threads federates, like put into law that if you have to have activity pub. The other one is blow open enough holes or make it legal for people to blow open holes in such a way that someone else will do it for them. And there's nothing that threads can do about it. I think this is more like two-part epoxy, right? Adversarial interoperability, the right to reverse engineer and stuff.

At EFF, we call this Comcom competitive compatibility because adversarial interoperability is so hard to say. Comcom is very good. Yeah, Comcom is great. So Comcom is great, but it is unstable, right? Because you are finding a blind spot in the intrusion detection system or the anti-automation stuff, and you're exploiting it and you're making it work. You're playing a cat and mouse game with thousands of engineers designed to stop you. Yeah, I mean, they have to make no mistakes. You have to find one mistake. You can stockpile 20 vulnerabilities and roll them out one after another as they plug one and then the other. There are lots of ways that this will be advantageous, but it is unstable. You know, in the days when Mintz started, you know, they were scraping like 6,000 different bank websites. And if the bank took active countermeasures to block them that they couldn't overcome, what they would do is if you were a mint user, they would just pop up a message that says, like, sorry Bank of America customer, we are no longer

capable of scraping this account. Here is the phone number of the lawyer who sent us the C&D for Bank of America. Call them up and tell them your Bank of America customer who wants to access your own financial data. Right. So there are lots of ways around this. And mandates, on the other hand, you know, formal formal requirements, as we said, they're hard to enforce or administer, but they are very strong, right, if firms actually hew to a standard, the standard works. You know, you never buy a USB cigarette lighter adapter in a fishbow at a fishbowl at a gas station only to find that it doesn't work in your cigarette light or receptacle in your car. Standards really work, but they're brittle.

So you have something that is very flexible but also doesn't hold very well. And then you have something that is very strong but is easy to break. And you combine the two and you get two-part epoxy, something that is resilient but strong. And that's why I think we need to combine both of these approaches. And that's why we need to understand that what tech has done through its regulatory capture is on the one hand, get broad latitude to abuse us, and on the other hand, create broad prohibitions on self-help. And we need to reverse that circumstance so that we have broad prohibitions on abuse of conduct by tech firms, whether they're large or small, and we have

broad latitude as users to take measures to help ourselves. After all this time and effort and Amazon purchases and Docker downloads, I've now built a couple of things that stick. I have a Plex server, which rules, and I now use it all the time. I also now have all my notes in a collection of text files, and I'll never use another note-taking app that doesn't read and write to that folder of text files stored on my computer. The two apps I'm switching between right now, if you're curious, are Noteplan and Obsidian. Obsidian, like we were talking about, is super powerful, but NotePlan is just really pretty, so I just keep coming back to it. I also still have image running, but Docker takes up too much memory on my computer most of the time, so I mostly don't

use it. I did rig up a way to use my B-Link mini PC as a universal file backup for all my stuff, but I also still have everything in Google Drive, too, because cloud services are great. It's much easier to get at my stuff in Google Drive. I just like having options. And I like that my stuff works now, even when AWS or Google Cloud doesn't, or when I'm on the train and don't have any Wi-Fi at all. I'm not really doing all this for big moral reasons, or because I'm afraid the cloud is going to get sentient and rule us all, or because I think we should destroy the tech giants. I just like my stuff being my stuff.

And I don't think that's too much to ask. All right, that's it for the Vergecast today. Thanks so much to everyone who is on the show. And thank you, as always, for listening. This is the last episode in our connectivity series. The whole series has been super fun. If you missed the earlier episodes, go check them out. And we have another fun mini series coming up starting next week.

So stay tuned. This show is produced by Andrew Marino and Liam James. The Vergecast is a Verge production and part of the Vox Media podcast network. We'll be back with episodes on Wednesday and Friday, talking about antitrust trials and video games and lots of other stuff. See you then. Rock and roll.