Backend Banter

**Kyle:** [00:00:00] We've trained fewer than a billion people that you get to be part of the web because you happen to be in a privileged part of the world that has enough bandwidth and enough.

Electricity infrastructure, to simply

treat. The web as this unlimited

resource that you can just reinstall a web experience. Every time you visit it, you can re-download the whole 10 megabytes of JavaScript and images

and We have an entire industry "web performance optimization" to solve the problem of how do we get an entire application across the wire and reinstalled and have it look almost instantaneous?

And that's like a created problem, . Taking about two thirds of the world that doesn't have those privileges and treating them as second class citizens or not citizens at all. You're not gonna solve big problems like that by just inventing a new framework. You're gonna have to completely rethink the way the web works.

​

**Lane:** Kyle Simpson, [00:01:00] welcome to Backend Banter. It's great to have you on the show.

**Kyle:** Thank you so much. It's a little outta my comfort zone since I usually play in the front end, but I'm really looking forward to this

**Lane:** Yeah, this should be fun. I mean, I mean, What you guys are doing is very kind of data oriented and architecture oriented, so I think it'll be really fun to, to dive into some of this stuff. I, I was just browsing Twitter one day when aj I, I guess a mutual friend of ours now had you on his podcast, or I should say the podcast, he co-hosts San JavaScript Jabber and suggested I reach out to you to bring you on and talk about socket supply and what you guys are doing with this distributed architecture of web applications. Do you mind

just taking a second to Yeah, go ahead and introduce yourself.

**Kyle:** Yeah. So for those of you who maybe haven't heard of me from this audience a lot of people in the JavaScript world have heard of me through a series of books that I wrote called You Don't Know, js, uh, those who've been around now for almost a decade. It's been a long time. But, um, That's kind of how I've mostly been known.

I've done a lot of speaking and teaching and advocating for JavaScript and [00:02:00] open web technology over the years. And I just recently started Back in January at Socket Supply, tiny little startup with big dreams of reorganizing the Web's architecture. So that's what we'll chat about today, but it is still fundamentally all in on the idea that the web is our future and we wanna make the web the best that it can be.

**Lane:** Yeah. I think betting against the web at any point in the last 25 years has been a really bad idea So it makes sense to just keep betting on it. So tell me what you guys as socket supplier doing and what makes it so different from the traditional way we've thought about just the internet in general.

**Kyle:** So there's two ways to explain it. One, I'll explain the company perspective, and then I'll also explain my personal perspective on why I joined. So to start with the company perspective, socket Supply provides a small runtime. That can wrap around a traditional web application, something like a pwa, a progressive [00:03:00] web app, that sort of technology.

We build a native app runtime that can wrap around that so that that app becomes an installable app that you would get in a normal app store. So in that sense, we are in a similar. Position with things like Towery electron, maybe React native. There have been many other players in the space over the last 10 or 15 years.

We've going backward. We've got, uh, ionic and we've got All the way back

**Lane:** and everything.

**Kyle:** of the original. Yeah, exactly. Ba back to the original phone gap, which became Apache Kor Cordova. So there had been a lot of entrance in this space is the point in making. And we are another one. We do have some differences between us and the current world of those app run times.

So for example, if, if folks are familiar with Tre, that's a big player in the space right now. Tary encourages you to take the front end, the UI of your web application and put it in the [00:04:00] web view that they wrap around, but they encourage you to write the backend of your application, that sort of backend, or even what I might call the middle end, but the back end of your logic, they encourage you to write that in rust and they put it in a separate process on the device.

So you have your main UI process and then a separate process that is your more traditional. Backend process on mobile devices. That works really well because mobile devices already, their operating systems already isolate those processes and prevent a lot of security creep. But on desktop, when Atari app is targeting a desktop, that is a lot more troublesome to us because the main process is not really protected in any way.

So a malicious app really has full control over a desktop. architecture in that way. So one difference between us and Tori is that we don't have any backend process. We encourage the entire app, all the U, all the ui, all the middle [00:05:00] or backend logic, all of that to be in the web view. There's no going to learn rust and there's no having to, figure out how to make sure that you're safe on a system.

So what that does is it allows the browser standard security models, the csp Security headers, that kind of thing, to control that communication from the web view out to the rest of the device. So we've doubled down on that architecture to compare us to somebody like Electron. Um, electron doesn't really target mobile, and a big reason for that is because of the size of Electron.

They really only target desktop apps, but they ship with 150 megabytes or something like that. Uh, our runtime is really small and targeted at a, at a couple of very specific. Characteristics. So we're not trying to ship all of node with it, for example. So our runtime is 1.5 megabytes ish on desktop, and it's about eight to 10 megabytes on mobile.

So we're trying to be really thin, really small, and really targeted at what we want to do. So [00:06:00] that kind of positions us in the space of runtime apps, runtime native app architectures or hybrid app architectures for web apps.

Similar to those other ones. And then if you want to take my reason for wanting to join, that's the company's original positioning.

My reason for joining Socket is because I really deeply believe that the web has made some unfortunate decisions over its lifetime in its centralization. If you go back to the early days of the web, The web was originally, and I'm talking like eighties, nineties, timeframe. The, the web was originally much more of a kind of mesh, a graph a peer-to-peer, if you might use that term type of

architecture,

**Lane:** connect

to your friend's server, right? Rather than,

**Kyle:** Exactly there. Your bill, your, your bulletin boards, whatever. There wasn't a lot of centralization back in those early days of the web [00:07:00] and through a variety of reasons, both technological, but especially business and money, , unsurprisingly, the web centralized itself. We centralized first on servers and then when that was more difficult for people to manage.

Then we had the advent of the cloud over the last, say, decade or so. And so the web has gone into the centralization model, but the, there's a couple of really unfortunate implications of that.

Number one, we have taught literally billions of people to believe that their data is not actually their data.

Not only do they not control it, because once they create a piece of data, it's immediately slurped up into the cloud and now it's owned and controlled by some big corp. And that corp doesn't even really own and control it. It's the even bigger trillion dollar Corp that runs the cloud that actually literally owns and controls it.

but we taught people that,

we also taught people that they don't have the responsibility of [00:08:00] their own data. They don't have control, but they don't have responsibility. And that's led to massive losses in our privacy. And, we could spend hours and hours and hours talking about all the implications of that, but it's also meant that

we've trained fewer than a billion people that you get to be part of the web because you happen to be in a privileged part of the world that has enough bandwidth and enough.

Electricity infrastructure,

if you will,

to simply

treat. The web as this unlimited

resource that you can just reinstall a web experience. Every time you visit it, you can re-download the whole 10 megabytes of JavaScript and images and

all of that other stuff. because caching doesn't really work that well on the web.

So a lot of that just gets redownloaded.

We have an entire industry web performance optimization to solve the problem of how do we get an entire application across the wire and reinstalled and have it look almost instantaneous?

And that doesn't, you know that that industry doesn't even exist for native apps, but it does for the [00:09:00] web.

And that's like a created problem,

which is actually.

Taking about two thirds of the world that doesn't have those privileges and treating them as second class citizens or not citizens at all.

They cannot participate in the web cuz they don't have unlimited and fast internet access. Even with things like edge server computing, like they just, they can't get the web experience that some of the, some of us get to enjoy as a privilege.

And so those. Those two things really deeply impact me and they motivate me because the web should be a level playing field for everyone, and it should be first and foremost about us owning and, and having the responsibility of our own data. And so you're not gonna, you're not gonna solve problems like that with the next like server client hybrid framework, react server component.

Like

you're not gonna solve big problems like that by just inventing a new framework. You're gonna have to completely

think,

rethink the way [00:10:00] the web works.

And that's what motivated me to join Socket because I had been thinking about what if the web could move to this more peer-to-peer model. What we call a local first.

We didn't, we didn't invent the term local first, by the way. But the local first movement we've embraced, the local first says not just like with offline first, but like your data should just primarily reside with you on your devices instead of your data. By default resides up in the cloud, owned and controlled by someone

else. So those, those are reasons that I wanted to join because I saw Socket as being able to really tackle that problem in a web changing

kind

**Lane:** Yeah, that, that makes a lot of sense. Let's, so there was a lot of stuff there that I want to break down and unpack, especially for some of our listeners that are a little newer to this stuff. Let's start with kind of the origination of the web. You said back in the eighties and nineties we had this more distributed. Web. What did that like? I think a lot of, particularly my listeners might not be familiar with, like how [00:11:00] the internet worked in the eighties and nineties. Maybe some of them used it, maybe some of them didn't use it. Maybe some of them weren't even alive. Let's, let's talk about that. How,

how did the web work if you are browsing in 1995?

**Kyle:** Yeah, so the web was basically that each person. That had some content that they wanted to share. They were encouraged to just be the sharer of that data. And so it literally used to be that you would, you would have a machine in your room, in your apartment, in your office that you would spin up, you would turn on and you would connect to the internet, and then other people would connect directly to your device.

To get information and that looked in the early days, things like bulletin board systems where people ran forum discussion forums and things like that. And the early websites of the day actually looked a little bit like that too. People started when, when web browsers started to come around in the, in the nineties.

Then we started to see people serving up experiences that weren't just [00:12:00] text-based but were more graphically oriented, but they were still doing so. From, because that's what we had. So we just, we served it from those locations and there really weren't a lot of those centralized. We're gonna house the whole web on

our server infrastructure types of things back

so our, our.

of course, that that meant that people had the opportunity to do and that's why they started moving in that direction.

But they, it was not originally that way.

**Lane:** So are, are you as like a hobbyist in the nineties, like exposing your IP address to the public and

connecting DNS to it? Like

what, what does that look like? From a, I want to actually do this standpoint,

**Kyle:** Yes. Yeah, exactly. So it, it was early primitive forms of, of what you just said. Yeah. Effectively, you, you didn't necessarily have a static location, but you, you definitely could pay for a static location. I actually remember coming along, kind of in the late nineties and starting to do some of this, I spun up like some [00:13:00] servers that I ran literally out of my college.

Dorm apartment, and I went to an internet provider and I was like, I want to have the same IP address every single time I'm connected and I wanna stay connected. And that was like a thing that they would sell to offices, but not a thing that they would sell to a college student in a dorm. So I had to like wrangle my way into getting

static IP addresses.

I p V four, that was like literally dedicated to me. And I actually had a, a, a a slash 16 block. So I had a whole bunch of these addresses just for me. Um, and I, assigned an individual IP address to each one of these different,

you know, machines that I was running. So it was kind of like that back in the early days.

Uh, Not everybody had the ability to have. A static IP address. So there were other ways that people would if they had to change, then they would communicate through other channels. My location has changed to this. Definitely. That was when DNS was really coming into its own, because we needed a way to find where you were if you had changed.

And so that [00:14:00] was yeah, the early days looked a lot like that and it was not uncommon for you to come on and, and try have to work to find. Something that you used to knew, know where it was, you had to do a little bit more effort to go and find where they were

**Lane:** Yeah, so like I remember playing StarCraft one Warcraft three, where like when we said you need to connect to a server, I like, I think it literally meant like you're connecting to a server right now. When you play, if you play like a big online game, you're connecting to a. The cloud server, right?

Everything's in one

big data center and everyone's connected over over networks. Whereas yeah, before it was like, no, like you needed to literally be connected to the same machine as your friend. And, and you're both going to play. Like I, if we all sat in the same room, in the same room to play Warcraft three together, like maybe my other three friends would connect to my

computer and like my computer would be the server for our little game.

**Kyle:** I remember back in the day, in the early days of Xbox, we did this, this was a little bit past what the timeframe that we're talking about, but when that, when the [00:15:00] first Gen Xboxes came out and we were, of course, everybody loved the game Halo. I would gather with my friends every Friday night and we had

Four Xboxs. He had this huge house. We had four Xboxes, one in each room, like giant kind of like gathering room of this house, and four of us could be on each Xbox, but the Xboxs were locally connected to each

other in a LAN. And we did LAN gaming

that

was, you know, a thing back in the late nineties and early two thousands, and we would just play like 16 of us in these massive all out war.

Battles with each other. So it was, it was more like that in the earlier days of the web. People organized their own subnets, if you will, of the internet by saying, we're gonna gather together, we're gonna do this thing. And sometimes it was like a permanent installation, like a thing for a game or a bulletin board.

And sometimes it was just these ephemeral things that people would gather in a convention center and set up a, a hub of the internet for a brief period of time and everybody connected into that while it existed.

**Lane:** Yeah. Now land gaming is is basically [00:16:00] gone. If I'm sitting next to my friend in the same room, we're playing a game, we're probably both connected to the same server in US

**Kyle:** all the way out to the cloud.

**Lane:** Yeah. Yeah.

So let's talk about that shift. So after we had this decentralized ish internet in the eighties and nineties, we started moving towards these centralized servers. And my understanding is the primary reason for that is, is, is basically convenience. It is a lot easier for me to play. StarCraft two or Agent Empires four with my friend now, because we don't have to worry about setting up local internet, like setting up lands, right? We don't have to figure out my friend's IP address so we can play together. Everything's connected. E even like looking at some other games like World of Warcraft, you used to only be able to play within one server. and like you'd only see one fragment of the world, but now with like larger infrastructure, you can see all of the other players in the game at the same time almost due to this centralization. So was it primarily a convenience factor at first?

**Kyle:** I think it was primarily, For a couple of [00:17:00] things. Try to make things a little bit easier and a little bit more scalable. And so it's, it's a legitimate set of concerns that drove this evolution combined with the , always follow the trail of the money, right? Knew back then that there was no way for one big giant corp to take much of a slice of things if everything stayed decentralized.

So they were certainly keen to sell the idea that, hey, if you just put all of your bulletin boards on our set of servers, then it would be so much more reliable. And if something went down, we could immediately bring up a new one and put it back in. Its, so there was a lot of, Selling points that did seem to tick off the boxes of convenience, of reliability, even performance, right?

It, my connection to the internet from my dorm was not as good as the connection that I could get if I co-located in a server center. So eventually, a few years after running it in my dorm, I had servers that I [00:18:00] was paying for rack. Space on a rack in a co-located data center because they had a fatter internet pipe and I could get, a faster connection, faster upload and download.

performance and convenience and reliability, robustness, all of those were very compelling reasons why little by little, the fragmented, decentralized web started to congeal into. Fewer and fewer centralized hubs with many, many spokes.

**Lane:** Got it. So now let's talk about how, and, and I'm gonna go back and review some of the stuff you said about socket supply. So you have this, this, this app wrapper. And I know a lot of my audience might not be super familiar with how mobile applications work, but correct me if I'm wrong, what you're, you're basically doing is taking maybe some sort of node js runtime or JavaScript runtime, maybe it's the browser runtime WebView, and you're running web applications in a native wrapper that is compiled to native code [00:19:00] so that these apps can run on a user's mobile device, even though it's essentially a webpage.

**Kyle:** Yeah, it is like that. Let me

make sure I'm, I'm very clear on things. Every single major computing platform today has a built in web view, which is effectively . A headless web browser. Something a lot of people may not know is for example, on Windows the, the like Windows 11, the latest versions of their operating system, significant chunks of the operating system user interface itself actually run through.

The built-in WebView, WebView two on the Windows platform. So actually little by little, more and more of the computing platforms that we don't think of as being web have moved to the web stack for a variety of reasons. Like we said, the web has always been this really good bet, and so you've seen it creep in even to operating systems.

So what that means is all the mobile and popular desktop. Platforms we're talking about Windows, [00:20:00] Linux, and Mac. We're also talking about iOS, we're talking about Android and even Chrome os. Those are the major computing platforms that people target for app and user experience today. And they all have a native web view that runs in them.

Think about Chrome os. It, it literally is an operating system inside of a web view. And so what we are doing is saying we don't need to ship the web view. , we don't need to ship that. And un unlike something like Electron in its early days where they're like, we're gonna ship the whole web view.

We don't need to do that. It's already on the device. It, it is different in the different operating systems and somebody's gotta write the like glue code to figure that stuff out. So that's what we've done, but we don't need to ship the web view. We're just gonna use the native, most performant, best available one for your platform.

**Lane:** Got it.

**Kyle:** What we are doing is saying your entire web app runs inside of that web view. Like a web app would run inside of a browser. So think Gmail, think Google Calendar. Think Google [00:21:00] Docs. Think Canva. Any of those like web application experiences, Photoshop, all the office suite, they've all moved to these web.

application experiences, right? We're saying you keep building stuff like that. Keep building web applications, using the web technology that you know, we'll put it inside of a web view, but to get. Access to some things that the device has that web does not natively have access to. We need a runtime around that, and our runtime is written in the native code of that particular platform, so c plus plus or Java or whatever it needs to be for each of those different platforms, our runtime says we are going to take capabilities that.

We need to expose to the web view and inject those into your web view so that they're just automatically appear in the global space of your web application. There's three specific things that we put in. We put in full file [00:22:00] system access, we put in full Bluetooth stack, and we put in a full networking stack.

All three of those are things that the web has very limited hobbled versions of APIs for, and we are putting in full. Fully secured, but full and fully capable, not hobbled versions of that, we are exposing those in your web application environment. That look a lot like node APIs, but this is not node at all.

Node is, this big thing with a whole bunch of capability. Most of that we don't think is relevant to building these kinds of apps. So we are committed to putting only in there what you actually need to take advantage of the full device. And those three are the big three. There'll be a few others I think that we'll ship probably like geolocation, a few other things that are hard to do, the more advanced stuff without.

Uh, Native capabilities, but that's what we're doing is this thin little wrapper around the web view. We ship your web app code and [00:23:00] run it in the web view, and then our code runs around the outside of the web view to give it these additional capabilities.

**Lane:** Got it. So I'm hearing two two benefits here. So if I were to compare. What I'm hearing to React native. So React native is another way to write your JavaScripts in or, or write your JavaScripts write your apps in JavaScripts specifically with the React framework and get access to a bunch of native capabilities.

It sounds like you are doing that, but you're not necessarily tying it to react. You are exposing these lower level APIs that, mobile dices make available things like the file system or geolocation through. JavaScript api, so you can just write your web app. And we also might need to touch on the distinction between a web app and a website. It sounds like this is more tailored towards web apps that you like load and then do a bunch of dynamic stuff in, like you said, like a Gmail where it's not really a static website that you just go and look up some information on, rather it's maybe an app that you load and you see all of your own user specific data. on. So that's like [00:24:00] the first thing that I heard, which is okay great, I get to write mobile apps in web technologies, right? Maybe I know html, CSS and JavaScripts. I wanna write mobile apps. And I can do that without learning the native stack. And then the other one that you said was really interesting to me, cause this is the first time I've heard this, is you are not shipping. A web view, which is obviously what like electron does, right? It wraps up the entire basically chromium browser and ships it down when you install, slack or Discord or what have you. So it sounds like you also get these kind of lightweight benefits. Am I, am I summing that up

reasonably?

**Kyle:** Yeah. To start in reverse. That's the, that's the main reason why we don't have to ship 150 megabytes to a desktop is cuz we're not shipping chromium, we're not shipping a web view. We're just gonna use the one that's already there. We think that's the best option, both for security and for performance reasons.

Certainly that makes our lives more complicated because we have to deal with all of the differences between the web view on Windows. And Mac and Linux and the mobile operating systems, that makes our [00:25:00] lives more difficult and, and it's definitely challenging, but we think long term, that's the best strategy because why ship a web view onto a device that already has a web view?

There's absolutely no reason for that. If the device is a powerful web view, even a few years ago, that wouldn't have even been a reality. because not all devices had a web view, and the ones that did, they were significantly hobbled. But we are seeing, fortunately, this shift to say that the web is a stack in an in, in and of itself.

And so they're embracing the idea. That it should just be a, a native core experience in those operating systems. And that's all to our benefit, because now we can hook into that and ship really good high quality performance experiences inside of the WebView. But it is a web experience. We're not doing for example, react native.

They're actually transforming your code. Into native code. They're transpiling your React code into native code for each of those platforms. We're not touching your web [00:26:00] application logic at all. We're shipping it as is bite for bite exactly the way that you write it, which means you have full freedom of choice.

You can use whatever frameworks or tools or no framework at all. If you're like me, I, I like to write vanilla , however you want to write it and build it. We just ship it into the web view. So we are a little bit different to something like the Native script or the React Natives or some of those others that need you to kind of transform the code to work.

We just allow that stuff to run in the WebView. Um, Some of the trade-offs are that you're not necessarily going to get. Platform native UI rendering. and this has been a big debate that the world has had about should an should every Android app look like an Android app, and should every iOS app look like an iOS app with the iOS native app controls and things like that, and people rightly.

Come down on both sides of that divide. Some people are like, [00:27:00] absolutely the, that is part of what makes it so awesome to make an iOS or an Android app or, or Windows or Mac or whatever. And other people are like, eh, we're all building all these custom, experiences and designs and controls anyway, so it doesn't matter, right?

So I might be a little bit more in that latter camp because I actually think that it's good for experiences to. To be different and for us to be able to take advantage of different sorts of capabilities. But some others are like more dead set on the iOS button has gotta look like the iOS button or it doesn't feel right.

So that is one of these explicit trade-offs is that we're saying, we're not going to try to put the iOS button on top of your app like that. We don't think that's the way to go. We'll let you build. What kind of experience makes sense for your app? With html, css, and JavaScript. So just use those skills and keep doing that.

But now you get to do it for every platform instead of just a couple.

**Lane:** Yeah, so I, I'm kind of in the same boat in the sense that I don't, [00:28:00] I don't really care too much if my app looks like an Android app or an iOS app, but I have heard, isn't it a little more performant to use the native built-in UI stuff rather than downloading the H T M L and c s s.

**Kyle:** There is still that predominant belief that using the. built in UI rendering will be more performant. Going back to what, what I said before, I think that is rooted in multiple years ago thinking where the web views really were second class citizens on in these operating systems. The shift is moving to them having full fidelity and that means full performance.

And yes, that's not. A fully true statement yet that it is still a little bit less, but I think it's the gap is shrinking rather than widening. And that's a good trend for us to piggyback on is we're saying that will become the more dominant way for the operating system to drive its rendering.

And it probably, it maybe already [00:29:00] happens. I don't know all the internals of say, the iOS architecture, but I wouldn't be at all surprised if they're rendering some of that stuff using their own web views anyway. and so it probably won't be long before you'll just be able to do the same kinds of form controls in a native app versus a web app on an iOS device.

I wouldn't be surprised if that eventually happens because the web as a stack is just so compelling to operating system developers that they've just weaved it in

directly, right? They know that people, they know that third parties want to build in it, but they also want to build in it, and that's why they've made it a first class citizen.

**Lane:** Yeah, that makes a lot of sense. Okay, so up to this point, we've had front end banter and we've talked about how how we can distribute essentially client side bundles of htm, L c s and JavaScript, or even native code down to like mobile devices and desktops. And in, in one sense, you could say that there, there is a backend side of that, right?

Some server is just doing the distribution of those client side bundles. But a lot of times when we think about [00:30:00] backend development, what we're really thinking about, things like rest APIs and GraphQL and, and more traditional APIs that kind of serve raw data down to clients so that they can like, render your feed on YouTube or your feed on Facebook, or maybe show you a vis visualization, right?

If you're looking at an analytics dashboard. The name of your company is Socket Supply, and you've mentioned several times peer-to-peer, but so far what we haven't, we, we haven't really talked about peer-to-peer, so how does what you guys are doing relate to how you think about the data that actually fills these client site applications?

**Kyle:** Yeah, it's a really great question and probably what I'm most excited to come on a banter show and actually get some banter about. So

fair warning to the audience. We're now gonna shift into here's a content warning. We're gonna shift into the more controversial opinion, but we we're, we are actually of the belief that.

if you do everything that we just talked about by distributing the front end of your application onto devices, [00:31:00] and if you buy into that, that's a better model than every single time I visit a website. I have to wait for spinners while everything re downloads or whatever. If you believe in that and we, we really genuinely do, it's actually not a much bigger leap for you to say why can't the entire application.

Just reside there. Why does there need to be part of your application on the device? And then all of the communication has to slurp up all of your data and send it up to some cloud server. Now again, we talked about the reasons for the centralization, and they were legitimate reasons, but we don't think that they're permanent inherent reasons.

We think that they're just. temporary choices for the last couple of decades. We've temporarily chosen that and we believe that we can shift our focus and make a different choice as a web. It's not gonna happen overnight, it's gonna take a long time. But what we believe is that if you take a different view of the web, which is that the entire experience can actually be on my device, the experience that matters to me, [00:32:00] I do not need, for example, , all of the petabytes worth of Gmail server data to run just what my emails are on my device, right?

I only need views of the last couple hundred of those emails, the ones that I'm likely to click on or search through. That's all I need on my device. . So Gmail is not giving me the full data set, and that's one mindset shift that I think people are gonna maybe feel a little bit uncomfortable about here.

But when we talk about moving to a peer-to-peer web, what we're saying is you need to embrace the idea that it is no longer true of almost any web application out there. It is no longer true that there's one single global source of truth. , we think of there as being like the one master database for Amazon e-commerce or the one master database of what is the Twitter, social feed or the one Mac.

But that's not actually [00:33:00] true. There are tens of thousands of different slices of that data running in different parts of the world, and they are sinking with each other, but they're, we, we had this term for a while that we used to throw around called eventual consistency.

**Lane:** You're talking about CDNs, by the way, right?

**Kyle:** Not, not really. I'm talking about like database synchronization,

CDNs or dis

distribution

**Lane:** distributed database

**Kyle:** about. Exactly right. So we have this term like eventual consistency, like my, my 10,000 different databases are communicating with back channels and they're updating each each other.

But the reality is that they're never consistent. So we, I think we should just embrace the concept that, that we're in a never consistency world rather than an in eventual consistency world. There is no one single global source of truth for any app. And because that is the case. That's actually beneficial to us to say, lean into that.

Basically put one version of the small little slice of source of truth on each one of your [00:34:00] customer's devices. So you've got thousands or millions of customers. That means there's thousands or millions of different little slices of the overall collective source of truth. But nobody needs to know the overall collective source of truth

at any given time.

Yeah, you, you might want to collect information so that you know how much you have an inventory or whatever, but like you don't need all of that to sit in a cloud database when you can simply start distributing these things. Now the big question that everybody's gonna ask is, If I put all of that data for Kyle on Kyle's device and all of the other data for Lane on Lane's device, how are Kyle and Lane ever going to interact with each other?

How are they ever gonna send a message to each other in a social app? How's Kyle ever gonna buy, a game from Lane that he's selling or whatever? Like how are they ever gonna communicate? And that's where peer-to-peer comes in because. My device and your device are inherently capable of talking to each other without a cloud server middleman, [00:35:00] but nobody's doing that yet.

And that's what socket really, that's, that's what sets us apart, is by exposing a full networking stack. We've invented, we've des described and, and standardized, if you will, a peer-to-peer protocol. Where an app on my device and an app on your device lane can talk directly to each other. And so the data that you need from me and the data that I need from you can exchange between our devices directly encrypted, secure but we don't need a cloud middleman for that to happen.

And that's the real game changer. That's what sets Socket apart is because we don't just wanna make it a little bit easier to render your UI on a device. We want to change the way the web works by drastically reducing reliance on the cloud. Most of what happens in the cloud doesn't need to happen there, and that means that most of what you're paying for the cloud, you don't need to pay for.

**Lane:** Yeah so this makes immediately. My, I have a couple things. The first one is, this sounds [00:36:00] to me almost like at first, the first way you described it as like the, the next step or like a, a more extreme version of like firebase or super base in the sense that like the app now in order to render UI logic is mostly fetching from its own local cash on your device and only going to a server when it needs something from the rest of the world.

That was like the first place I went. And then when you talked about getting data directly from peer to peer, Yeah, this is where I think we'll actually have to jump into very specific types of applications to talk about how they would work in this paradigm and, and if they would work better or worse.

Because immediately I can think of stuff that like, almost like obviously seems like it would be better, right? Things like dms, ,right? It's like I could DM you, you,

could DM me. That one's pretty easy. In fact, I

don't want it going through. Yeah, exactly. Like, you know, We have these kinds of apps uh, in, in some sense with like Telegram or whatever. Um, That do some of this kind of stuff or file downloading, right? If you like to go back to Limewire and these like [00:37:00] old

peer-to-peer networks.

But something let's take the example of an e-commerce site. So if I'm an e-commerce vendor traditionally what I've done is shove the database in the cloud, maybe put WordPress in front of it or Shopify in front of it, and you go to my website and you transact with me. And, you're paying me and I'm keeping track of inventory in my database. Is that a stack that makes sense for socket supply? And if so, how does it, how does it work?

**Kyle:** This is what I'm most excited about because that's the place that a lot of people's minds go to. They're like, yeah, yeah, yeah, that's great. Except we do e-commerce and we could never do e-commerce peer-to-peer. And I actually think that e-commerce might be an even better example of it, but it really requires twisting your brain around.

So you're all right that the most natural place a lot of our brains jump is when it's small amounts of data directly from one person to another. But you could actually think of commerce. in that same vein. if you, if you really take a [00:38:00] step back, so let's think about something like Amazon as the example of giant e-commerce.

We think we need a giant petta base, petabyte sized style, you know, database centralized or whatever, because we need to know all of the inventory. That's not even how Amazon works, right? They definitely do have Large databases that keep track of stuff, but like probably more than half of what Amazon sells.

They're just connecting or reselling for somebody else and they're getting their data and, and showing it to me.

**Lane:** Right.

**Kyle:** Why does their, the, that other vendor's data need to go into Amazon to then come back to me? Why couldn't I just see from that other vendor that they have five of this game that I could buy that data?

only needs to come to my device for the stuff that I'm looking at. I don't need the entire billion item inventory database on my device. I'm only gonna look at a couple of items. I might need some information, some basic information for doing search results and [00:39:00] stuff. But here's the beauty of having a peer-to-peer network because all of the data that I need, Is out there among all of my other peers, all of these other people, because other people are all searching and looking at different subsets of the same search results.

So all of that data is actually just a couple of hops away from the nearest peer device to me on the internet. And so when my device running an e-commerce app, like Amazon says, I need to find this stuff out. It is actually querying out to hundreds or thousands of my peers and collecting all of that data and beginning to render and show me that data.

Instead of going all the way up to the mothership cloud server and saying, you tell me what the slice of view Kyle needs to see is. I only need a tiny little slice of that and I can get just what I need from the peers around me. Now there are parts of this that are going to feel more naturally like they need to be centralized.

Let's talk about the actual [00:40:00] credit card charging, for example, right? Um, it probably feels to most people, like the only way from, if you, if you had any exposure to doing e-commerce, and I have like literal current experience with

this.

**Lane:** like I use Stripe. I outsource it to another

**Kyle:** Yeah,

I was gonna say exactly, I use Stripe because I'm building this website to, for a table tennis club that I've started in town and I need to charge people and I'm using Stripe, right?

So it seems like there's gotta be servers for that stuff. . It is true that in our current Web 2.0 or what I would call the future of what I'm discovering, I would call web 2.5, so not all the way web three. It is true that there are parts of this that will still make sense, perhaps more centralized than decentralized, and.

Processing credit cards is certainly one of those things. Sending out emails or infrastructure that is already inherently centralized and we're not gonna see SMTP protocol for email delivery. Decentralize

**Lane:** I was [00:41:00] gonna say emails actually counterintuitive cuz it started out decentralized as

an SMTP protocol. And then it's centralized. And so you're saying that actually it does make sense to keep it centralized.

**Kyle:** Probably, but I think of those things as legacy protocols that eventually go away and be replaced by better, more privacy protecting and more efficient alternatives. So email was the perfect asynchronous delivery mechanism before we had peer-to-peer as an option. But once we have peer to peer as an option, I think we can start to model email light communications in an asynchronous way of a peer-to-peer network without needing the email protocol, but, We are still gonna have billions of people with email addresses for a long, long time.

So there will still be an email server in a cloud somewhere that when you wanna send out a receipt to them and they are gonna receive it at their email address, you're gonna send a a notification to the email server, send them out an email, and that's still gonna transact. In the traditional server way.

[00:42:00] So I, I think what you should think of if you're listening to this is that we're not suggesting that all of backend and all of server and all of cloud goes away, but there are significant chunks of it that are just co-located there because it felt most convenient. , and that's actually where you're spending most of your cloud spend on.

It's also where most of the complication in all of your glue code is, and we're saying get rid of the complexity, get rid of the performance, get rid of the user privacy violation, and just put all of that stuff directly on people's devices and leave the, leave the servers, leave the cloud for the stuff that kind of.

Has to be there, but much more of that can move decentralized than you are probably thinking. Actually, a lot of that can peer-to-peer, and that's where we think the real, game changer is. So even in something like e-commerce, we can see that most of that experience would be decentralized. And maybe only the last moment when I click the, I'm [00:43:00] submitting to purchase it, does it have to go back up to a central server to reconcile with the credit card system?

But then it sends the the message back out to the peer-to-peer network to say, Hey, you send him this email and you send him this product and you send this and you update this data so that everybody else knows that that game's been sold or whatever. Most of that can still come right back to the peer-to-peer.

And then you start to think, web three has been trying to convince us that even commerce itself can be distributed peer-to-peer through things like the blockchain. We are not a blockchain company. We don't have any blockchain check tech at all, but I, I call us Web 2.5 because I think we're pretty friendly to the idea that if that is our future 5, 10, 20 years from now, I think it's a while out.

But if that's our future, Then even stuff like Stripe could be replaced by a decentralized commerce. So if you've already built your entire e-commerce experience around decentralized and peer-to-peer concepts, except for that last little bit that you had to send off the [00:44:00] stripe, and then somebody comes along and says, Hey, here's another way of doing that, where you don't even need to pay for the server anymore.

Now you're not needing to re-architect your whole app to do web three. You're just taking a tiny little piece and switching it onto the blockchain.

So we consider ourselves to be a much more friendly way of moving the web in that direction, but you don't necessarily have to ever embrace blockchain or Web three to take advantage of A lot of the web can decentralize itself onto people's

**Lane:** it, it sounds really interesting. I'm excited to see where you guys go with it. I love seeing how this kind of stuff progresses over the years. I have, I, I want to like, Talk just a little bit more in depth about e-commerce for about five minutes. And then lastly, I wanna just give you like the chance to, to tell us what you think the perfect use case for Socket Supply is.

Like where you think it makes the absolute most sense. So first to dive back into e-commerce for a second, I have just a couple of questions. I've worked a lot with like big distributed databases and one of the problems they solve pretty well, Is [00:45:00] I, it's, it's exactly the problem you described where maybe I'm browsing Amazon and I have a search query, and I want to get all the results for a specific search query.

But not only do I want to get the results, The company that is feeding them to me, the, the seller of the stuff wants to give me the most relevant stuff at the top. So there's like a sorting thing going on.

And, and, and from what you described earlier where you said, basically if I, if I load this search query on say an Amazon app, I'm gonna go fetch all this data from, from, thousands of different devices and render it. I see two, two potential problems. The first is That sounds like an insane amount of bandwidth, right? I've gotta connect to a thousand different devices so I can render one page potentially to go patchwork all of this data that's living on all the, all these other devices. And the second problem I, I potentially see is as the seller, if my customers are just haphazardly getting data from all of these different places. How do I know that they're seeing like relevant stuff? What if I want to like change, the order in which they're seeing my products?[00:46:00] So I

guess a performance and then like a customer experience problem.

**Kyle:** Yeah. Great questions. I'm glad you're asking those. So first off, To talk about this performance question for a moment to go and get all of that information from Amazon server you, you establish one pipe directly to an Amazon cloud server somewhere, and they're going to shove down many, many megabytes worth of data to you to render that whole set of search results to you, right?

All of the images, all of the product descriptions, and current quantity and all. You should think about Amazon's webpages just. Just a ton of information that's being shoved down to you. Almost all of that was. dynamically rendered. It was dynamically computed and fed to you. Well, What we're actually saying is that the same experience, the same information that I need as a consumer to look through results and make decisions and say, I wanna look at this, but that one's definitely not what I'm looking for.

I need it in black and not blue, and [00:47:00] they only have black or whatever. All of that stuff. That's, that could actually be fed by drastically less data. So rather than counterintuitively where you might think this is gonna require me getting megabytes from thousands of people, you only need to get like less than a couple of K kilobytes from each other person.

So what you're doing is taking, instead of one giant pipe of all of this stuff You are getting tiny fragments from everyone else and the tiny fragments add up to far less than the one big thing because your app now has the ability to start rendering only the stuff that you need and it can just not, it can just ignore the stuff that you've already scrolled past or that you didn't even scroll to yet.

So it doesn't need that information yet. Like by fragmenting this out, you can actually have the opportunity for your app to. Request far less information. Also because the latency is much lower, you can request on demand, like literally as I scroll, you can just go and fetch a few more packets and render a few more things instead of having to go [00:48:00] get this huge set of results and render the whole thing.

One of the reasons why that can actually work more performantly to have a thousand of those going out. It's more like a hundred, but let's just say a thousand cuz that sounds cooler, the one of the reasons why a thousand of those can actually be more efficient. It's because our networking, our peer-to-peer networking is built on UDP instead of tcp.

TCP is heavily, heavily overloaded with a lot of stuff on top of it, and I think, somewhat argue that TCP has it's on its way out, if you will. It's not going to be the predominant protocol that drives the future of the web. We've already seen a lot of TCP three TCP be ditched by the HCTP three slash quick protocol that Google and others came out with secretly without a lot of people knowing.

Most of the web's already upgraded to that anyway, and most of the web is not actually using the traditional dedicated

**Lane:** and can you just quickly, from a super high level, explain the difference between TCP and udp?

**Kyle:** [00:49:00] Yep. Very, very high level is that TCP is we need to have a two-way handshake. We need to agree that you and I are talking and I'm gonna send you stuff and you're gonna send me stuff. And when I send you stuff, you're gonna say, I got it. And then vice versa. I'm gonna say, tell you that I got what you sent me.

So there's this very chatty protocol that's dedicated channel

**Lane:** So like multiple

network round trips just to send

essentially a response.

**Kyle:** right? And and built into that is encryption and compression and all of this other stuff, not all of which is actually even relevant for each connection, but it was this one size fits all protocol that most of the first 20 years of the web was built on.

Thank you uh, TBL for inventing things like this I'm glad we have it. It got the web to where it needs to be, but most people that are serious about this infrastructure stuff know that TCP is not the future. And so you see things like quick and stuff. They're built more on the concepts of udp.

There's, it's even more complex than that, but they're built more on these concepts where we can actually [00:50:00] have different negotiations in the same channel, because we don't need all of those same overheads for every single packet that's being transmitted. UDP has. Far less overhead in each packet. The header can be just a couple of dozen bites instead of hundreds and hundreds of bites or a kilobyte worth for each T c p packet.

So what we see is that we can get these really tiny packets that traverse very, very efficiently. The downside, of course, is that in UDP there's no guarantee I might send out a hundred of these packets and like 50 of 'em might arrive and 50 of 'em might not arrive. So we do have the, that, like you and I are chatting over one of these web things, almost certainly our audio and video is being transmitted at some part of the transport layer through udp.

Because if a frame is missed or a single little bit of my sound is missed between you and I, Nobody cares. It doesn't matter. So stuff can get lost. You can, you can have these lossy communications. When you wanna do lossless, high fidelity communication, you do start to have to reintroduce on top of U D P, some of the concepts [00:51:00] that TCP had, like knowing that the packets, a set of packets have arrived and you need to be able to reorder them,

**Lane:** If I wanted to download high fidelity video rather than stream live, for example.

**Kyle:** My, my, my, my perfect example is not even audio video, but like a file. If I'm gonna send you an image, I've got a cool little funny meme gift that I wanna send you or whatever. I might send that in a hundred different packets to you, right? And those are gonna go out. I mean, I'm gonna send them out in order, but they're not necessarily gonna arrive to you in order.

And in fact, you might get 90 of 'em and a hun and 10 of 'em got lost somewhere along the way. How does your side know A, that I have all of them and B, that I need to reassemble them in order. But we actually use a, a, a borrowed concept from the blockchain, which is just the mathematical concept of chained hashing to.

To create a signature for every single packet and every single packet has a previous packet to it, and there's account of how many those are. And so the receiving side knows definitively when [00:52:00] it gets even one packet, it knows exactly which packets it needs still to get, cuz it knows what it needs in the chain.

And so if it misses something, it can re-query the network and say, does anybody have that packet? I still need that packet. And then it can reassemble all that stuff definitively in order through that signature chain. Just

Shaw hashes. It's nothing more complicated than that, but it re reassembles that and it can do that so much more efficiently than the equivalent of TCP having to do all of this other, compression and handshaking stuff to make all those packets work.

So I can send you this file. Your side gets all of this stuff, and only once it gets all of it, does it then render the image for you. Might that take a little bit longer? It's possible. We are simply saying that we're embracing the idea. That a lot of the web can be asynchronous. For example, I might send you an image file and you might not even be online.

So where do those packets go? Our peer-to-peer network is relay based, meaning that I'm gonna send out copies of those packets to a hundred different people. that I am [00:53:00] connected with, and they're all destined for you. They're all encrypted so that only you can read them, but they're gonna be residing in the relays and bouncing around the relays of hundreds or thousands of other devices.

And then I go offline and I'm having fun with my kids or whatever. You come online and you start advertising, Hey, here I am. And you start receiving those packets from other people that have been bouncing

around. And then those packets arrive and once they've arrived, boom. Up pops the cat meme, pick

**Lane:** This, this sounds, this sounds really fun. I've always been a big distributed systems nerd. I'm, like I said, I'm really excited. I wish I had another hour to just dive into individual use cases. But it sounds like, yeah, like at the very least you've convinced me there's, there's definitely some, some use cases that, that seem to make a lot of sense for this. There's others that I, I, at least after our 10 to 15 minutes of chatting still seem like it would be really hard to get out of a centralized server, like an elastic search or something, something crazy like that. But I do wanna give you just a bit of time to, to tell me what do you think would be like what app [00:54:00] or, or site or product makes the most sense to, to like seriously consider socket supplies peer-to-peer network as like an infrastructure shift.

**Kyle:** Yeah, so I think some key examples of this, we've already touched on the, the concept of messaging, whether it be direct messaging or even just group messaging, but private group. Kinds of chat or mess chat, messaging, chat, things like that. I think business productivity, the whole suite of business productivity where you're synchronizing information asynchronously about project updates or things like that.

Even live collaboration, things like those whiteboards and, the, the Canva experience and, and things like that. Those all actually make a ton of sense. In a peer-to-peer world, cuz again, I don't need all of the whiteboards at your company to be synchronized to my device. Only the one that I'm currently viewing right now. right

And so I can get only that data updating directly from the people who are doing the updating and it can be a lot lower latency and more efficient. But I'm gonna go out on a limb here and say that while there are some [00:55:00] definite architectural challenges, I actually think maybe the best.

Example of how this could change the web would be large scale social networks built this way. We've seen, for example, the growth of something like Mastodon to try to be an answer to the centralized Twitter. And right now Mastodon is still based on this concept that we need to have different servers that we connect to physically

**Lane:** Federated servers. You

pick one. Yeah.

**Kyle:** federated things and Right, and, and that's better. That's going a little bit further back to the way the web used to be. That's good. But it's nowhere near what it should be. I think building a completely distributed social network on peer-to-peer is actually where this would like, if you could do that.

And I definitely believe this is totally possible and I hope somebody is gonna go do this. , if you could build that version of it completely on the peer-to-peer network, I think it would take everybody's mindset and completely shift it and holy crap, we can do a, a huge global social network because nobody ever needs the whole [00:56:00] social network.

They only need the, like the people that, that they talk to and that they're following or whatever. They only need

tiny

**Lane:** need their section of the graph. Yeah.

**Kyle:** Exactly. So I think that's actually gonna be one of the most exciting things is I think we'll see people build big, big stuff like that. On this very simple, concept of architecture.

Imagine being able to run a Twitter with $0 spend. Twitter must spend like what, like a million dollars a year on their cloud or

**Lane:** Can you imagine? Yeah.

**Kyle:** stopped paying his cloud bill. What if you could build a Twitter experience and pay $0 for it because it was completely distributed?

**Lane:** And more

private and yeah,

**Kyle:** yeah, exactly. I think it would completely change people's minds about peer-to-peer if we saw that happen.

**Lane:** it, it might make social it, it might get rid of the, so the stigma around social media as well. That would be exciting.

**Kyle:** I, I think it could return some, some, some sanity and some maybe some civility back to the process when you could decide what part of the graph you cared to, to be safe in and, and ignore the part of the graph that you didn't want to be

**Lane:** [00:57:00] Yeah. This has been fantastic. Thanks so much again for coming on, Kyle. Where can people find socket supply? Where can they find you? I don't know if you do like the Twitters and things like that, but go ahead and, and, and let people know.

**Kyle:** Yeah, for sure. So our website is socket supply.co. We've got links to our guides. We've got first time experience information on there so you can figure out how to install it. I should have emphasized this at the very, very beginning. Socket Supply is a free open source framework. You don't pay us a single penny for this.

You download it, you build your apps. You

d you distribute, build a billion dollar business. You don't have to pay us anything. We do have paid services on there. We have, and, and I shouldn't even call them services really, but they, they, we have apps that you can pay for. To analyze the traffic, to do performance monitoring, to do tuning, figuring out what's happening geographically with all those packets, that kind of stuff.

We have one click deploy, so we have this app called Operator that does a bunch of this really cool stuff and we've got multiple paid tiers that you can get into with that stuff. But you can [00:58:00] start literally, by just downloading a free framework and building and, we don't want to be the middleman there.

So we're not like a service provider where your bites are coming through us. We want you to build this distributed thing. So go to our website, check out our framework. We've got a Discord channel where we're regularly and actively talking. We've got multiple couple dozen people that are actively building apps right now.

So if you wanna come to that that kind of nascent community and ask your questions, it's a great time to get in before you know the million other people are there. Ask those questions and say, Hey, I wanna build this thing and I wanna try it out. I wanna see if I could build it. I currently am building a little game on it, and it's like a, it's like a realtime game.

And so there's some challenges with realtime communication but there's still things to figure

out. We're gonna work on a realtime protocol on top of our peer-to-peer protocol. And so there's a lot of exciting stuff. So I hope people will just come to our website, check out our guides, download our free framework, and join our Discord channel.

That would be awesome.

**Lane:** Amazing. Thanks again, Kyle. I'll talk to you later.

**Kyle:** Thank you.[00:59:00]

​