How to Build Peer-to-Peer Mobile and Desktop Apps with Socket Supply - JSJ 588

Kyle Simpson is a Human-Centric Technologist, Author of "You Don't Know JS". He joins the show to talk about "Socket Supply", building "local first" web apps, and what his employer in Socket Supply is doing in this space. They also talk about building native desktop & mobile apps.

Special Guests: Kyle Simpson

Show Notes

Kyle Simpson is a Human-Centric Technologist, Author of "You Don't Know JS". He joins the show to talk about "Socket Supply", building "local first" web apps, and what his employer in Socket Supply is doing in this space. They also talk about building native desktop & mobile apps. 

On YouTube

Sponsors


Links


Socials


Picks


Transcript


Charles Max Wood:
Hey folks and welcome back to another episode of JavaScript Jabber. This week on our panel we have AJ O'Neil.
 
AJ O’NEAL:
Yo, yo, yo, coming at you live from tears of the kingdom.
 
Charles Max Wood:
Oh, I wanna try it. We also have Dan Shapir.
 
Dan Shappir:
Hello from a really sunny nice weather in Tel Aviv.
 
Charles Max Wood:
I'm Charles Max Wood from Top End Devs. Go check out our book club, topendevs.com slash book club. We have a special guest this week. It is Kyle Simpson. Kyle, welcome
 
Dan Shappir:
Yeah!
 
Charles Max Wood:
back.
 
Kyle Simpson:
Yeah,
 
Dan Shappir:
Carl Simpson!
 
Kyle Simpson:
thanks. It's, it's been too long. I'm glad to be back.
 
Charles Max Wood:
You don't know multi-platform JavaScript, isn't that how it goes?
 
Kyle Simpson:
Yeah, I think so, yeah.
 
Charles Max Wood:
Do you wanna just remind people
 
Dan Shappir:
Oh, I've
 
Charles Max Wood:
who you
 
Dan Shappir:
missed
 
Charles Max Wood:
are
 
Dan Shappir:
you,
 
Charles Max Wood:
and,
 
Dan Shappir:
Kyle. I've missed you, Kyle.
 
Charles Max Wood:
right?
 
Kyle Simpson:
It's great to see you, Dan. Great to see you, Chuck and AJ. I'm glad to be back. Yeah. A quick, quick little refresher. If people don't know who I am, you may have heard of a little book series called, you don't know JS. Um, somehow I managed to write those books. That's how a lot of people in the JavaScript world know me. And some like me for it. Someone, some don't like me for it, but that's how I'm known at least. Uh, uh, more recently I've, uh, you know, I've done a lot of speaking and teaching. advocating for the open web platform. And more recently, part of what we're here to talk about today is I, uh, part of a startup called socket supply. And we have a tiny little vision about completely reorganizing the web. So that's what I'm digging into these days.
 
Charles Max Wood:
So I just wanna know, does it come with socket wrenches? No, I'm just kidding.
 
Kyle Simpson:
It is deliberately a pun. It should make you think like a hardware
 
Charles Max Wood:
I figured.
 
Kyle Simpson:
store.
 
Charles Max Wood:
So,
 
Dan Shappir:
Yeah.
 
Charles Max Wood:
real quick as we jump in, what I'm always interested in is, and it seems like there are other people trying to solve the problem of kind of the multi-platform, one code base, I don't know, thing. Like, what is the problem you're trying to solve? What's the problem space you live in? And then we can kind of dive into, okay, and what's the solution?
 
Kyle Simpson:
Yeah, for sure. So going back 15 ish almost years, um, some of, yeah, maybe not quite that far, but at least 10, 12 years back. Some folks that have been around long enough may remember kind of the early entrance in this space, like phone gap, which became, was renamed and became the Apache Cordova project. There've been literally like a dozen or more of those kinds of frameworks that have come out from native script to ionic to more recently react native. We see Towery, Electron. There's a lot of these different players who are trying to create. Run times that wrap around web applications and make them so that those web applications can target in a native application format, all of the various different platforms, or at least most of them. So, uh, we are joining that space in one respect in that that is what socket supply provides is an open source runtime. that wraps around a web application like a PWA and turns it into an installable native app such that it could be in the iOS store, it could be in the Play Store on Google, Windows, Mac, Linux, et cetera. We are definitely different in some specific ways that we'll dig into, but generally broadly, the idea is that the web is this ubiquitous programming language platform. But it doesn't always have parity in integration with device capabilities, whether that be device APIs or certain types of functionalities that a device has that it can do with a native app, but they don't expose those to the web APIs. So this idea that we create a runtime that augments the web application capabilities to bring it more closer to parity with native apps. That's been around a long time and socket is kind of the newest entrance to that space. So hopefully that provides a quick overview.
 
Charles Max Wood:
Yeah, I think
 
Dan Shappir:
But
 
Charles Max Wood:
people
 
AJ O’NEAL:
Okay.
 
Charles Max Wood:
have been dreaming about this for a while with, I'm thinking React Native, Capacitor, stuff like that, right?
 
Dan Shappir:
Before we dig into the value and limitations, I also think, of this model versus the, let's call it the regular or the legacy web model, I understand that socket supply has another significant aspect to it that goes along with it. And that's kind of... how the fact that it kind of skews servers for a different model. So could you explain
 
Kyle Simpson:
Yeah,
 
Dan Shappir:
that as well?
 
Kyle Simpson:
definitely. Let me get into that. But before I do, let me just say that it, that is the thing that we think puts socket supplies framework in a class of its own is there really isn't anybody else doing that, but if you think about simply the space of can I use socket supply to create a traditional web app, but with augmented runtime capabilities, like a native app, like the react natives and Towers and whatever. One specific thing to point out is that we have a bit of a different approach there even than those existing players. So we do not support or promote a backend process that is separate from the WebView. You put your entire application in the WebView that we wrap. We expose APIs. But Towery, for example, promotes a separate backend process. Now, on mobile platforms, that's pretty okay and safe because the mobile OS is have some pretty good sandboxing of those apps. But if you were to use Taury for example, a desktop app, the backend process that ships in that app is completely open to do whatever it wants to the device. There's no security restricting that main process, only the web view. And so for that reason, we don't support or require doing a separate backend process. We don't ask you to learn Rust to do that the way Taury does. You just put your entire web application in the web view and to contrast with with electron, which does not target mobile currently electron ships about 150 megabytes of overhead on a desktop. We are 1.5 megabytes of overhead for our tiny little runtime. And on mobile that works out to about eight to 10 megabytes worth of overhead. So we're trying to target a smaller, but we think better subset of that space. Now to get to the the question that you asked Dan about what is it that we think sets us apart really and truly and that is that one of the main capabilities that our runtime adds, we do have full file system access, we have full Bluetooth access, but full networking access, meaning no restrictions the way the web APIs currently restrict you. You can't really do full client server kinds of networking in the browser because the APIs just don't allow it. And we think that once you've installed an application as a user, you're inherently saying it is okay for you to do all of these full things. So the web APIs should allow that for installed experiences and they don't. And that's always been one of my frustrations personally is that once I install a web app, it really should have all the same capabilities that a native app has, it should not be locked down the way a drive by website needs to be locked down. But they kind of always danced in the middle. Like they give you a little bit more capability, but it's still locked down. And so our APIs are extending this to full access, of course, with security controls, but full access. But with that networking protocol, we have designed and launched with that. A full peer to peer serverless, truly serverless protocol, meaning that an app powered by socket can communicate with another instance of an app powered by socket. and have no server whatsoever. And there are a bunch of really difficult problems in that space in the peer-to-peer world. Obviously we're not the first to try peer-to-peer, but we have a protocol that finally solves zero server nat traversal, zero server signaling between peers and the discovery of the network and all of that stuff. That all happens over UDP with no servers whatsoever. And so to really summarize why this is such a game changer. Is that applications that currently think that they have to put all of their, what we would call backend logic in the cloud, their database management and, you know, storing all of the data or whatever, essentially that becomes all optional. So any business of any size that is paying anything whatsoever for the cloud could start to go through and realize that with building with this peer to peer protocol and with our runtime, your apps can eliminate most or all of your reliance on the cloud. meaning that you're dropping off that whole bill from your overhead. And we think that businesses are going to get pretty excited about that.
 
AJ O’NEAL:
Okay. Okay. So I have to ask this first and foremost, because I go to your website and you're talking about peer to peer
 
Dan Shappir:
Thanks for
 
AJ O’NEAL:
and
 
Dan Shappir:
watching!
 
AJ O’NEAL:
you're talking about getting off the cloud and the cloud model to me means economies of sass rather than economies of scale economies of scale, one banana, $1, two bananas, $1.50 10 bananas, five bucks, right? That's economies of scale economies of sass, one banana free, two bananas, $5, three bananas. Call for enterprise pricing. And that's the thing that I think is evil about the cloud. But
 
Kyle Simpson:
Okay.
 
AJ O’NEAL:
when I look at socket supply.co that's your website, right?
 
Kyle Simpson:
It is correct.
 
AJ O’NEAL:
Okay. Your business. I don't even know what this is, but this is more than what AWS costs for. I mean, eight 99 a month. That's that's a hefty, you know, so this is hacker free pro one 99 business eight 99 three banana call for enterprise pricing. Explain yourself.
 
Kyle Simpson:
I will explain myself. So first of all, we're an open source framework and you can run a billion dollar business without paying us a penny. We are not a service provider. So none of those prices that you see quoted there are because we're the middleman being the service. You can take our open source framework, build whatever you want on it and never pay us a penny. We hope that you'll want to pay us for our expertise in providing tooling that analyzes this peer to peer network. helps you understand where your customers are, where bottlenecks are, where performance issues are happening. But our tools are simply analyzing the same network that you could analyze. So there's absolutely no required cost to grow to an infinite size business
 
AJ O’NEAL:
Well,
 
Kyle Simpson:
based
 
AJ O’NEAL:
what's
 
Kyle Simpson:
on our model.
 
AJ O’NEAL:
what? So then what socket operator and why are the bridge plugins the S3 to P2P Dynamo DB to P2P Lambda to P2P? Why do those only start at the 199 a month tier and that's I mean, that's hefty for a month.
 
Kyle Simpson:
The,
 
AJ O’NEAL:
I don't
 
Kyle Simpson:
the,
 
AJ O’NEAL:
know what
 
Kyle Simpson:
uh...
 
AJ O’NEAL:
this is. I don't know the value is but that's what what is it doing? That's that
 
Kyle Simpson:
Okay.
 
AJ O’NEAL:
that's expensive.
 
Kyle Simpson:
Yeah, that's a great question. So again, we hope that companies as they get larger, we'll see the value in purchasing licenses to the software that we've built. That's what the operator app is and some of those other plugins. So we are taking parts of the application development process that are difficult. For example, real time monitoring and especially real time monitoring of a global peer to peer network. That is a difficult problem to solve. And we are experts in that since we designed the protocol. So we've built an app and a way of analyzing that that makes it easy for you to do. But none of that is like something that you couldn't figure out on your own. If that's the way that your company wanted to roll, you would not have to use any of those products. But what we're talking about with those plugins that you're referring to. is that we have a variety of different things that we've tried to streamline. So for example, one-click deploy to app stores. You could go through the process and if your company already knows how to deal with app store deployment, builds and all that other stuff, you can do that yourself. But if you find that you're doing that a lot and you would like to streamline that, we've provided a one-click deploy to all the app stores, for example. So those are examples of features that are streamlining the development process. the management and analysis process. That's what we're charging for, but the tool to actually build the app open source and free, and you can use it as much as you want.
 
AJ O’NEAL:
So,
 
Charles Max Wood:
Nice.
 
AJ O’NEAL:
but again though with the plugins, it seems like the plugins are something that I would probably need to build an app that some sort of storage like S3 to PTP. I'm reading as a storage layer for peer to peer, an object
 
Kyle Simpson:
It's,
 
AJ O’NEAL:
storage layer for peer to peer. That
 
Kyle Simpson:
it's,
 
AJ O’NEAL:
seems like something
 
Kyle Simpson:
it's,
 
AJ O’NEAL:
you would need.
 
Kyle Simpson:
it's not quite that actually.
 
AJ O’NEAL:
Okay.
 
Kyle Simpson:
What that's actually designed for is companies that have huge deployments in the cloud and are going to migrate little by little from the cloud to peer to peer. These are adapters that go into your existing cloud installation and help them start talking to the peer to peer network. So a very large company that was already spending a hundred thousand a month plus on their cloud bill. They might not want to roll all of that at once and release one whole update that changes everything. They might want to go little by little by little. So those incremental steps, again, they could invent their own kind of incremental upgrades, if you will, to the peer to peer way of working. We're providing tools that make that easy. So those are connectors into your existing cloud infrastructure that help them talk to the peer to peer network while you're doing your migration, which Again, for a large company that migration realistically is probably a multi-year process. You're not going to overnight rewrite your entire application logic in peer to peer launch it, and then just be done. You're going to do, you're going to progressively turn off cloud services once the equivalent peer to peer application experience is already fully, you know, bulletproof tested and all of that. So in those migration periods, which could be anywhere from a few weeks for a small company to multiple years for a large enterprise. That's what this tooling is designed to help you figure out.
 
Charles Max Wood:
Nice.
 
AJ O’NEAL:
So I would think, generally speaking, the way that I understand markets is that if you enter into a market as competition to an incumbent, you lose. Meaning if there's a well established company that does something and you're trying to do something that's incrementally better than what they do. So you, you are going up against Honda and you want to create a car and your car is 10% more efficient. You're going to lose because at best
 
Charles Max Wood:
Hmm.
 
AJ O’NEAL:
case scenario, Honda is just going to buy your patents and then Honda is going to be 10% more efficient. If you create a low end disruption, then you are targeting customers that those businesses don't want. So you want to create a, well, that's Honda is a bad example because they create every type of motorized vehicle at this point, but okay, the segue, right? You want to create the segue or a motorized skateboard. Honda is not going to win against you over that because you're, you're creating a new low end disruptive product that the, the profit margins are really, really low. And so you Honda is not going to compete with you if you develop a, an electric skateboard because they're selling, you know, on the low end, $10,000 cars, and you're selling on the high end, a, a $2,000 skateboard. So when I look at, when I look at this, I think our, our enterprise businesses that can afford to pay eight 99 a month. Are they, are they the ones that are going to be adopting this new low in technology that's disrupting the market? Or is it going to be, you know, people that are starting new businesses that have open minds, that have fresh ideas. Cause I like, I'm interested in what you're saying, right? But now we look at network stats. It seems like, okay, as a hacker, as some dude, who's just like, I want to create a new thing, I want to create something disruptive. I want to create something in the peer to peer space. It seems like network stats would be something that I would be very, very interested in, but there's no way that as a small business in a disruptive space, I could afford a price tag like 899. So what is the strategy here? Are you expecting like Google is going to switch to this or are you expecting that like small startups are going to do this and how does that work out?
 
Kyle Simpson:
Well, let me, let me broadly say that there are actually a number of companies. Um, there's a few very public ones that have been recently making. More noise about how they feel like the cloud is an unnecessary and bloated expense. Um,
 
AJ O’NEAL:
Yes.
 
Kyle Simpson:
I'm thinking, for example, a few months ago, 37 signals, kind of the, the base camp folks, they made
 
Charles Max Wood:
Mm-hmm,
 
Kyle Simpson:
a big deal about
 
Charles Max Wood:
they did.
 
Kyle Simpson:
how. They switched completely away from the cloud, went back to on-prem and how they had this drastic reduction in the complexity and the cost. And they're not the only ones, but they're just kind of an easy example to refer to. A company like that was paying tens of thousands or even hundreds of thousands of dollars a month for their cloud bill. And so an 899 cost point for them is probably not going to register very much. Right. They are the company that would absolutely run both architectures in parallel for a while. If they were, for example, to try this and, you know, there are conversations happening with them and companies like them. If they were to try something like this, they're the company that would run both of those architectures almost in an A B sense for a while as they were migrating until they were very, very confident that they had reached and exceeded the parity and quality. of their previous server and they're now a server, they're not cloud anymore. But if they were to take the next step from going to ons from going from on prime servers to being, to embracing the full peer to peer nature, maybe not reducing, removing all of their servers, but drastically reducing them. Um, they would be running both of those in parallel for a while. And they are the ones that would be happy to pay to get all of the information that you know, our professional. Analysis software will give them because that's a drop in the bucket compared to what they've already been paying. A small business that's starting out is going to use a free open source tool that we've provided. And they're not going to have anywhere near the traffic levels that are going to require them to have that analysis. So they wouldn't need to pay 200 a month or 900 a month or whatever, because they're not going to have anywhere near that kind of a traffic. And by the time they do, they're hopefully generating enough revenue that if they compared. that cost to what they would be paying for the cloud to get that. Um, actually they, again, paying way, way less for those types of services.
 
Dan Shappir:
So, I like to kind of pull us back from the discussion about the cost
 
Charles Max Wood:
I was
 
Dan Shappir:
and the
 
Charles Max Wood:
about
 
Dan Shappir:
business
 
Charles Max Wood:
to do
 
Dan Shappir:
model
 
Charles Max Wood:
the same thing.
 
Dan Shappir:
to talk for a minute about the technological concepts here and what you're the problem
 
Charles Max Wood:
Can I say
 
Dan Shappir:
with your
 
Charles Max Wood:
one
 
Dan Shappir:
action.
 
Charles Max Wood:
thing real quick though?
 
Dan Shappir:
Oh, go
 
Charles Max Wood:
Because
 
Dan Shappir:
for it.
 
Charles Max Wood:
I think Kyle's point is well made in the sense that, you know, I may try it out on the free level, start figuring out how to migrate it. I mean, the pricing makes sense if you look at it that way, right? Okay, now I'm reliant on it. I've pulled stuff off of the cloud. Now I'm looking at, okay, how do I get enough of the other information I need in order to make this easier to use? For my customers, easier to blah, blah, blah, right? And so now I'm starting to... capture this information and go, oh, okay, I've got heat mapping, I've got, you know, network stats, I've got, you know, paint and performance, right? And so I start making it feel better and look better. And so, yeah, I totally, you know, can kind of see the progression here, but I love that it's open source. And then, yes, I was going to say, let's talk about the technology because I want to know how to build on this because, I mean, I have some desktop and mobile ideas, several. And
 
Kyle Simpson:
Mm-hmm.
 
Charles Max Wood:
I'm sitting here thinking, okay, how do I use this sucker? Right. How do I plug this into what I want to build and say, okay, I've got a thing. And guess what? You can use it wherever you want.
 
Dan Shappir:
So, and to kind of add on top of what Chuck just said. So the part about creating native apps is really interesting and we'll probably want to dig into that, but that's less revolutionary, like you said yourself. There are a lot of other solutions, different approaches, we've had some recent episodes about the various ways in which this can be done, the benefits and limitations of each one of these approaches. But what really sets you apart is that whole peer to peer, kind of angle or tie-in. Now, if I'm thinking about the features that... So you're not really just doing away with the cloud. I mean, the cloud is kind of like the ultimate evolution that you're kind of like working against. But what you're really trying to do away is kind of like you said at the end, is like the whole need for the server in a sense. You just have the various peers working together. Now, if I'm thinking about the roles that the server plays, you know, it does a lot of things, but it really... from my perspective, can be really summed up in three things that a server might do, one of them, or two of them, or all three of them. One is it's kind of like the center or the hub. Like that's the one that everybody talks to and connects everybody together. So in a lot of systems, clients don't talk directly to each other, they all communicate with the server. And maybe even things start at the server if it's a web server. So that's one role. Another role is it's like the central data store or the holder of the source of truth as it were. Like the data that is the correct and valid data and the data that needs to be persisted, the data that needs to be shared, it resides at the server and that's the truth. that everybody abides by. They may have different views of this data, or they may have optimistic views of the data, but the actual truth is what the server holds. And the third one, which is the least important, is a place to do processing. If for some reason you want to offload some processing off of the endpoints to somewhere else. Now, unless you're doing really specialized processing, these days there's relatively little value in that. unless your users are using really low-end Android devices, you can probably get as much processing from the endpoints as you can get from the server in many cases. So for me, it's really more interesting about the other two aspects, how to get away from the server as something that kind of synchronizes the entire system and how to get by without... some sort of centralized data storage.
 
Kyle Simpson:
Yeah. Well, I like your framework of laying it out. I will build on it and amend it a little bit, but I like your framework of identifying some of the key things that a server is doing in the application architecture. And obviously if we make the claim that servers become more optional in this future version of the web, then we have to explain how is that functionality going to be handled when there isn't a server. So I think it's a very useful line of discussion. Number one, I would say when you talk about centralization, I would break that out into two subtasks, if you will. One of the reasons for centralization is, maybe even three subtasks actually, but one of the reasons for centralization is what we would call discovery. I wanna talk with you, Dan, but you and I have never connected before. And the way we traditionally think about the two of us getting paired up so that we can talk. We can do a document together or whatever, is there needs to be some centralized channel that we meet in and we are introduced to each other. And then we could even negotiate a peer to peer connection after that.
 
Dan Shappir:
WebRTC
 
Kyle Simpson:
But the one,
 
Charles Max Wood:
Mm-hmm.
 
Kyle Simpson:
exactly. So one of the reasons for centralization is this discovery problem. Another reason for the centralization is what we would call the synchronization problem. I make some changes to something and there's a view that somebody else has. of the same or similar data and my that change that I make needs to get synchronized to them. And so again, we think centralized hub and spoke architecture is the way to do that. I send my changes up to the server. It changes the state of things at the server and then somebody else, including one of my other devices, for example, but somebody else pulls down the changes down their spoke and they synchronize that way, right? So synchronization is another one of those driving reasons behind. that hub and spoke architecture. And I think another, maybe third one that may be incorporated in what you're talking about, but maybe not, is that people want the reliability of their data that if all of their devices were burned up in a fire, they didn't lose all their data. And so they like the idea that their data is permanently stored out somewhere in the cloud and the cloud never goes away. So I would articulate those as kind of primary reasons for the server being centralized we also you did you did point out this concept of What I would I guess I would call like the compute or the large storage use case and quite frankly peer-to-peer is not going to Be a really compelling answer for some of those uses for example if you're doing blockchain, you know Bitcoin mining or something like that
 
Dan Shappir:
Yeah.
 
Kyle Simpson:
if you're doing large language model training or things Things that you would be inclined to perhaps customize very specialized hardware for those tasks. Those are gonna stay in servers and likely gonna stay in the cloud. And we're not suggesting that all of that stuff would go away. What we are suggesting is that that other stuff that I'm talking about becomes optional. You don't have to do that in the cloud just because you're doing these other tasks in the cloud. Another example of where you're probably gonna keep using a server. is large file distribution, you know, CDNs distributing large video files. You're not going to be sending terabyte sized video files peer to peer. You're going to still probably be getting those from a server, at least for any time into the foreseeable future. So the negotiation of which file to download can happen peer to peer, but the file itself will probably still come from a server. So we're not saying zero server, zero cloud. The cloud completely goes away. We are saying that a lot of what we've stuck up in the cloud. And actually
 
Dan Shappir:
Thanks for
 
Kyle Simpson:
where
 
Dan Shappir:
watching!
 
Kyle Simpson:
most of the cost of the cloud that comes to these businesses does become more optional in this model. So to, to address some of those issues, how do we do discovery? When there is no central server for us to all connect to well in the peer to peer protocol that socket provides, and we don't think that's the only way a peer to peer protocol could happen, but we did the hard work to create one that we think is pretty compelling, but in the peer to peer protocol. Every person that has a socket powered app on their device, at least one of those apps on their device is automatically when that app is running, participating in this global peer-to-peer network. Which means that it doesn't matter which app you have, you have any socket powered app and you are running that app at that time, you are then online as it relates to the peer-to-peer network. And why that's useful is because your device will be relaying packets for everybody else around you in the network, and they'll be doing the same for you. Everybody is sending each other packets. Now all these packets are encrypted, so it's not like your private data is coming to my device and then I can snoop on it. Your private data is being sent out to the network, but it's encrypted for whoever it's intended for. So even though my device will relay it through its cache, I can't read it or do anything with it because I can't see it, it's fully encrypted. same strength of encryption as we rely upon with HTTPS. But all these devices are now, you know, thousands, tens of thousands, hundreds of thousands of devices. They all become collectively together a large cache of all the packets that are transversing through the network. I send out a packet to you, Dan, or to you, AJ, and you may not be online right now, but that packet's gonna go out to hundreds of other peers on the network. and be relaying bouncing through time across all those peers. And when you come on light later, eventually that packet reaches your device and you're the only one that can decrypt it. So you see that you can decrypt it and you receive that packet and do what you want with it. But one of the reasons why that network is beneficial for discovery is that everybody can see who a packet was destined for, but not who sent it. And by who I only mean their public key that it was encrypted for. And so that is actually how discovery happens is that by watching packets as they go through, you see the public keys of people that you might want to communicate with. So if you were in a social media app and it saw packets going through for public keys, it would be able to present these as, you know, anonymous entities at that point, cause you haven't connected with them, but entities that you could say, I want to send an introduction and see if this person is somebody I want to talk to. So at a network level and then at an app level, there's two layers there, but at the network level and at the app level, discovery happens naturally through a peer-to-peer network. And we can dig into some more of those details, but those things are actually handled very well by a peer-to-peer network. And one of the, I guess, key takeaways here is that, unlike, this is going back to something that AJ was talking about earlier, unlike... with traditional server and especially cloud centric architecture, the more people that you get as customers of your app, the more you have to pay to scale out, it becomes more expensive and more complex. In a peer to peer network, the more people you get, the easier and cheaper the process becomes. So it grows actually invertedly. You're actually, it's a little bit harder to get started and it's a lot easier to grow to a global scale.
 
AJ O’NEAL:
So with that, I'm assuming you still have some sort of seed that there are some seed servers that these apps connect to, to join the network to get started just like with the blockchains, right?
 
Kyle Simpson:
So what we have right now is we've got a couple dozen of those, what we call introducers. Those
 
AJ O’NEAL:
Introducers.
 
Kyle Simpson:
are basically free AWS instances running our protocol. Those introducers will be decommissioned, right? The plan is for those to go away. The architecture is designed such that once you've had enough peers joining a network, and we've done some modeling on this, we think it's in the few thousands to 10,000, but once there's enough of those active nodes on the network and you have connected before, to at least one other node, then you won't ever really need to talk to an introducer again. So eventually, introducers will become unnecessary. And apps will probably provide their own specific versions of those if they want to to make it easier for somebody to synchronize and get connected. But we won't be operating introducers eventually. It'll be fully decentralized.
 
AJ O’NEAL:
So even if there's a solar flare and everything on the planet reboots,
 
Kyle Simpson:
Mm-hmm.
 
AJ O’NEAL:
as they boot back up, they won't need the introducers for the network to reactivate itself.
 
Kyle Simpson:
What they will do is have the cash of all the people that they were previously talking to, and they will try to send packets out back to those same locations. And they'll send it to hundreds of those. And statistically through our analysis, at least one or two of those will respond. Right. So it's very
 
AJ O’NEAL:
Yeah, that
 
Kyle Simpson:
unlikely
 
AJ O’NEAL:
makes sense.
 
Kyle Simpson:
that if you've sent
 
Charles Max Wood:
Mm-hmm.
 
Kyle Simpson:
out a thousand packets, that all thousand of them are completely disconnected and you don't hear anything. And even if that does happen, you can still start sending packets back to those. And people will see those packets going by. And eventually you'll get picked up by the network, but you'll eventually, I mean, you, you very likely in a, in a large enough network, you'll eventually be reconnected within less than a second or two, because those packets go to quite a few different peers, not just one or two points.
 
AJ O’NEAL:
So is there is there cross pollination between apps so that it doesn't become islands of networks, but that the the network globally can persist?
 
Kyle Simpson:
Yeah. So the each app has each app on your device. Let's say that you installed five different socket powered apps on your device. Each one of those apps currently maintains its own completely sandboxed, isolated cache. So there isn't any cross pollination of discovery of one app to another. But I think in the future, we're going to have coordination between those caches mostly for the reasons that you discussed right now there, especially because on mobile, it's very difficult. Right now they're just
 
Charles Max Wood:
Yeah.
 
Kyle Simpson:
treated as separate islands, but it's important to note that an app's cache is app agnostic, meaning that it is able to forward packets for any other app type. So even if you have, you know, you have the Pac-Man game app and you are going to be relaying, you know, Twitter style, you know, packets that are coming through because you will have connected to a peer that had the Twitter app on it. And so they'll be sending you Twitter packets that you will relay on even though you don't have the Twitter app. on your phone or
 
Dan Shappir:
And again,
 
Kyle Simpson:
device.
 
Dan Shappir:
you relay things on to everybody. Who do you relay things on to?
 
Kyle Simpson:
There's it's a complex process of prioritization based on how quickly you've been able to connect and communicate with them in the past. So there's some sorting going on, but it's hundreds of different peer. If you've met and you know, obviously the first time you're connecting, you haven't met anyone. So the introducer is going to say, here's a couple of dozen for you to try to talk to, and then you'll talk to them and they'll tell you about ones that they know. And so your cash of how many peers that you know about and have tried to communicate with within a few seconds, it's in the thousands most likely. And so it's sorting that based upon how quickly it's able to communicate, how quick, how often that person, that peer is still online and responding to you and sending you packets. And that's how it prioritizes who to send your packets to, but it's constantly changing every time you disconnect and reconnect, kind of rediscovers it's nat type and reconnects to people and then resorts that list of who it should try to send packets out.
 
Dan Shappir:
And going back again to
 
Charles Max Wood:
Oh,
 
Dan Shappir:
the
 
Charles Max Wood:
come
 
Dan Shappir:
whole discussion
 
Charles Max Wood:
on.
 
Dan Shappir:
about how this replaces the need for servers, where does the data reside?
 
Kyle Simpson:
All right. So one thing that one key realization is that, um, I think that we've kind of one of the big lies that we've told ourselves is that for almost any application type in existence today, we think of there being that is cloud that is built cloud syndrome, we think of there as being one source of truth as you pass, as you posit it in your question, that the set that the server or the cluster of database servers represent the single source of truth. And we talk about things like eventual consistency. The reality is that for most application types and for most user interactions, there really is neither any central source of truth, nor is there even a need for a single source of truth. Most applications only need a tiny little slice of that source of truth, that global truth for the interactions that a user is going to have with them. Even something like Twitter. There's no such thing as I see every single tweet. You know, billions of tweets every single second coming through. You're only getting a tiny little slice of that. Even if you were to hook into the, the, the real time stream with, you know, that they have in their API or something. So there is no such thing as a global source of truth for hardly any application. And what we're, what we're suggesting here is that you can actually lean into that. What you can do is store the data on a user's device that they need. And that becomes the effective source of truth for their experience. And so really rather than there being one single source of truth, you have lots and lots, thousands, millions of different snapshots, slices of the global source of truth on all your customers' devices. And when your customers state, whatever it is, is impacted by something that somebody else does, whether that's another customer, whether it's a vendor supplier, if they've updated their inventory or whatever. When that data goes out to the application and they see those packets come through, their app will recognize the parts of that data that they need to synchronize with their state to update their state. So that will change my application's view of the global state, because that data will just propagate through the peer-to-peer network. So you do have to think about things differently, but you do not even need a central database, one single central database to run commerce like. web applications, you can actually do them fully peer to peer because for most of those interactions I don't need to see the whole global state of Amazon. I only need to see the state of the product I'm looking at and I can get that inventory information from a couple hundred peers that are nearby who also have that information.
 
Dan Shappir:
So, but at the end of the day, the way that you're envisioning it is potentially having something that kind of feels like a relational database or small relational database on every endpoint and every endpoint only getting that subset of the data out of it that is relevant to it, something along these lines.
 
Kyle Simpson:
Yes. And we're, and the way that all that merging logic happens, because for some applications, it's very easy. And for some applications, it's certainly much more complicated. Um, but all of those applications that are doing any sort of collaborative real time stuff, they're already using CRDTs conflict free replication data types, right? Um, CRDTs range in complexity from pretty straightforward, like last in last edit wins. all the way up to very, very complex merging strategies. But there are powerful libraries for this. And instead of running one CRDT on your set of cloud servers, you can simply distribute that CRDT logic to each app. So each app is running a CRDT logic that merges in with its current local state, anything that it sees happening on the network that it cares about, and it discards or ignores any information that it doesn't need to service that user's particular interaction.
 
Dan Shappir:
interesting and I'm guessing and I'm kind of potentially seeing some sort of blockchain tie-ins potentially
 
Kyle Simpson:
So we do not position ourselves as a web three company and none
 
AJ O’NEAL:
Good.
 
Kyle Simpson:
of what we've built uses any blockchain technology. I will disclose that prior to working for socket supply, I was working for a web three company. I worked for a company that does a smart contracts for the Bitcoin space. And I do happen to personally think that of the entire web three space, I think there is some actual legitimacy in smart contracts. But I believe that they are way further out from web two, that the gap is way too big, and that we're not just tomorrow about to realize the vision of web three. So I personally have been describing the non web three stuff that I'm talking about today and that I'm working on now, as what I would call web 2.5. I think we have years, maybe a decade or more, of transition that we need to go through, both architecturally and maybe more importantly, with user perception and behavior and responsibility. We've got a long way to go before we possibly could realize some of the promise and potential of some of the web three world. So I would call this pre web three or web 2.5. We're not using any of that blockchain technology that said, I mean, web threes, one of its big, you know, promises is a fully decentralized web. And they don't really have a lot of great options yet. for the decentralization of the front end. They have much more of an answer for the decentralization of the back end in the smart contracts. And so I think that we would consider ourselves to be web three friendly, but we in no way, shape or form are promoting a web three agenda. We're just trying to promote moving the web to this decentralized future.
 
Dan Shappir:
Now, I assume that your peer-to-peer protocol, based on your descriptions, is not WebRTC,
 
Kyle Simpson:
It is not.
 
Dan Shappir:
for no other reason that you're avoiding the whole issues around discoverability that have plagued WebRTC from day one and effectively, to a great extent, have caused it to fail. I mean, yeah, you see web-based video chat, like, the one we're currently using to record this podcast, but the vision of WebRTC data channels, I'm not aware of it having been realized at scale by any significant software that I'm aware of. If somebody who's one of our listeners is aware of something like that, feel free to drop me a line, but I'm not familiar with anything like it. And again, I'm guessing that one of the problems had to do with the whole concept. of discoverability and all the challenge of preparing those servers that get the whole ball rolling and to have it work across all network environments, etc.
 
Kyle Simpson:
Yeah. So I'm glad you bring up web web RTC. So I have several things to say about that. So first of all, web RTC for those that maybe don't know, or don't know how long this has been around, it's been around for a lot longer than a decade. So this is actually not a nascent technology. It's a rather well established technology. And in fact is actually on in the process of being phased out or deprecated for
 
Dan Shappir:
Oh yeah?
 
Kyle Simpson:
a future standard that they call web transport. It's going to web transport is kind of the future of web sockets and web RTC kind of rolled up into one, but even web transport is still going to be limited. If you read the spec, you're still not going to be able to do the, the true client server, meaning that the really what we mean is peer to peer. You're not going to be able to do peer to peer UDP networking in the future web transport, at least as the spec currently stands. So there are still limitations, but they're kind of fusing WebSockets and WebRTC together into WebTransport. I think it'll be several years before anything like that concretely is reliable, you know, cross-platform. So, we're not that. What we are is providing a UDP-based networking protocol from the core primitives of the device down into your web application through an API that looks much like Node's UDP socket interface. And so we're, we're allowing you to start communicating with UDP packets without any servers. And that's the other big thing with WebRTC is that, and even, you know, web sockets, they're, they're married together because in WebRTC, you can't make a connection that is peer to peer over WebRTC until you've been introduced. And that always required a server for many, many years. We've talked about, is there going to be a future where we can have zero server? Web RTC signaling is what it's called in the Web RTC world. Can we have zero server signaling? And I did see some interesting experience experiments into that. Like for example, tunneling signaling packets over DNS text records and you know, things like that. There have been some attempts to get away from it, but the standard, you know, the status quo right now is that Web RTC installations still require rather servers, they're called stun and turn servers that do the signaling, the intro, and in some cases, even the media relay, those are where the real, the real bucks get spent on the media relay. So we're almost undoubtedly running through a, a stun or turn server to do this call. And so at least some of our media relay is happening that way. And the reason for that is actually network infrastructure, a router, um, infrastructure. So we have this problem called NAT. network address translation and NAT traversal is an incredibly difficult problem. Now WebRTC has built into it a way of negotiating around NAT traversal and it uses the server to you know signal send the signaling is sending those packets back and forth but eventually two peers might decide that based on what information they're getting that's been relayed to them through those servers that there is no way for them to talk directly because they're both behind what we would call a hard NAT. And a hard NAT is actually just a cheap router. It's one that doesn't keep a persistent port open. But when you have two peers that are behind a hard NAT, they can't keep a persistent connection, TCP connection back and forth to each other. So NAT
 
Dan Shappir:
Wait
 
Kyle Simpson:
traversal
 
Dan Shappir:
a minute, WebRTC
 
Kyle Simpson:
is a very hard problem.
 
Dan Shappir:
though doesn't need to be TCP, I think it's also kind of UDP-based, is it not?
 
Kyle Simpson:
It signals through TCP and then it sends all of the media and stuff like that through UDP. But there's a, it like data channels have a reliable data channel form,
 
Dan Shappir:
Mmm.
 
Kyle Simpson:
which is TCP and the unreliable data form, which is just the lower level UDP. So that protocol takes care of all of that stuff, but it still requires servers for the signaling. And when two peers can't talk to each other, it still requires the, I think it's the stun server that does the media relay. right, which is the really expensive
 
Dan Shappir:
And you
 
Kyle Simpson:
stuff.
 
Dan Shappir:
do away with all that by the virtue of your UDP base protocol.
 
Kyle Simpson:
In a sense, yes. So, um, if we talk about the signaling portion of that needing some web socket server to relay, uh, signaling, you can still signal, you know, you can still talk to each other and negotiate connections. And again, our peer to peer protocol is doing all of that negotiation and signaling and that traversal stuff for you. You don't have to write a single line of code for that. Just like with WebRTC, you just say, I want to connect here. I am, I introduced myself and then you start hearing back. That is fully zero server. We have, that's kind of one of the unique things about our, uh, not type discovery or what we call nat reflection process is that we send out multiple packets and when we receive multiple packets back, we can compare the differences in response and that tells us what nat type we're in. So as long as there's at least two or three other peers that hear your outbound message when you connect, which there are now because of our introducers and there will be because of the future state of the network. As long as you get back at least two of those responses, your device is able to determine definitively what NAT type it's on. And once it knows that, it knows how it needs to communicate with others. And so if you find a peer that you cannot directly send packets back and forth to, then you simply won't connect to that peer. But you have all the other peers that you will be able to connect through and your packets will relay through them to these other people. So they will act like those relaying servers, but nobody's paying for those servers in the way that you're doing in WebRTC. Now with media, right, like real live video and audio, like we're talking about, you're probably not going to send all of those packets over the peer to peer network. You're probably going to want to have more direct connections. And so we are actually working on things that might look like a WebRTC kind of direct media protocol,
 
Dan Shappir:
Hmm, interesting.
 
Kyle Simpson:
real time stuff. as an additional layer on top of our existing network.
 
Dan Shappir:
So if
 
Kyle Simpson:
But
 
Dan Shappir:
after
 
Kyle Simpson:
in,
 
Dan Shappir:
just to,
 
Kyle Simpson:
let me just finish,
 
Dan Shappir:
ah, sorry.
 
Kyle Simpson:
let me just finish real quick. In the meantime, you can use our peer-to-peer network to do the signaling for a WebRTC connection. And that's
 
Dan Shappir:
Ah,
 
Kyle Simpson:
what
 
Dan Shappir:
cool.
 
Kyle Simpson:
we think will happen.
 
Dan Shappir:
Oh, okay. Interesting. Oh, okay. But at the end of the day, what you're saying is that once I discover another peer through this whole relay network, I can then, assuming the network allows it, create a direct communication channel with that other peer, and then I can literally do whatever.
 
Kyle Simpson:
Yes, exactly. I once you've, what, if the nat types are compatible
 
Dan Shappir:
Yes.
 
Kyle Simpson:
and you have a direct connection, you could establish a fully symmetric TCP connection with them if you wanted to. Um, and that's probably kind of one of the early versions of this is just established TCP, unfortunately has a lot of overhead to it, which is why UDP is.
 
Dan Shappir:
Mm-hmm.
 
Kyle Simpson:
Faster, but obviously UDP is
 
Dan Shappir:
H-E-T-P-3.
 
Kyle Simpson:
less reliable. So you have those, those trade trade-offs. Right. And so you see, that's why like TCP was ditched and as you said, in each We'll see things like that where apps will go ahead and establish their own direct connections with peers that they're able to. And if they're not able to do that, then they'll just keep relaying through other peers.
 
AJ O’NEAL:
So.
 
Dan Shappir:
Oh, go ahead, AJ.
 
AJ O’NEAL:
I was going to say TCP has some definite advantages other than reliability. One being it's easier to prevent abuse on TCP because the abuse control is built into the protocol. Whereas with UDP is very, very difficult to handle. Denial of service type situations. You can't, you can't put back pressure on a UDP connection. If you have an attacker. You can basically reverse attack an attacker and that's basically built into the protocol on TCP You can slow Loris the attacker and say okay I'm gonna handle your packets, but I'm gonna handle them so slowly that it's not gonna be a problem Or I'm just gonna let them drop with UDP. That's You know, so there's There it's not just UDP. UDP is our glorious savior. I just want to I just want to put it out there
 
Dan Shappir:
No, it's
 
Kyle Simpson:
Yeah, so
 
Dan Shappir:
also just to
 
Kyle Simpson:
I'm glad
 
Dan Shappir:
add,
 
Kyle Simpson:
you bring that up.
 
Dan Shappir:
just to add before that, Kyle, that, you know, that famous saying that was said about TCP that whomever, you know, decides to avoid TCP ends up reinventing TCP.
 
Kyle Simpson:
Well, uh, you know, I think, I think the folks that, you know, at Google that ditched TCP and went with the, the UDP based quick protocol would probably, um, maybe they would agree, maybe they would disagree, but they're smart folks and they know what they're doing. So I
 
AJ O’NEAL:
But
 
Kyle Simpson:
think
 
AJ O’NEAL:
that's
 
Kyle Simpson:
the future
 
AJ O’NEAL:
that's for
 
Kyle Simpson:
of
 
AJ O’NEAL:
YouTube.
 
Kyle Simpson:
TCP.
 
AJ O’NEAL:
That's for YouTube.
 
Kyle Simpson:
Right.
 
AJ O’NEAL:
That's not for blogs and and you know, that's not for Gmail. That's for YouTube,
 
Dan Shappir:
Why?
 
Kyle Simpson:
Most
 
AJ O’NEAL:
which
 
Kyle Simpson:
of the
 
AJ O’NEAL:
is
 
Kyle Simpson:
web
 
AJ O’NEAL:
a different
 
Kyle Simpson:
is already
 
AJ O’NEAL:
problem.
 
Kyle Simpson:
upgraded. Most of the web is already upgraded to quick without even
 
Dan Shappir:
Yeah,
 
Kyle Simpson:
anybody even
 
Dan Shappir:
exactly.
 
Kyle Simpson:
knowing.
 
Charles Max Wood:
All right, I'm gonna grab the wheel because I think there's some important stuff that we haven't covered. Go ahead, Kyle,
 
Kyle Simpson:
Okay.
 
Charles Max Wood:
and then I'll grab the wheel.
 
Kyle Simpson:
There's, there's one last point that I just want to address. I'm really glad that you bring up AJ, the attack vector of this protocol. We have built into our relay protocol, our peer to peer relay protocol that peers only forward packets for other peers. If those peers have been forwarding packets for others. So there's a natural balancing protocol that if somebody were to come onto the web and start flooding, start publishing, but not relaying for others. then they are automatically going to start getting de-prioritized down the list. And eventually all their packets will be ignored by all the socket peers.
 
AJ O’NEAL:
And that's like
 
Kyle Simpson:
So we
 
AJ O’NEAL:
BitTorrent,
 
Kyle Simpson:
have built
 
AJ O’NEAL:
right?
 
Kyle Simpson:
in some controls to keep the peer to peer network balance. I just want to bring that.
 
AJ O’NEAL:
Yeah, and that's like, that's like the way BitTorrent does it more or less, right?
 
Kyle Simpson:
It's similar, yes.
 
AJ O’NEAL:
And, but then how do you, how do you prevent the opposite, which is that, because it's super easy to spoof UDP packets because there's no, there's no session data and this is how the whole natural reversal works, right? Is you flood a bunch of T, uh, UDP packets out, you check which ones get received. You spoof, you basically spoof on both sides of the same time that you're both sending and receiving and hope that the port numbers aren't randomized so that you can kind of send a packet to yourself, get it back, see what the port number on the outside is, then send. 10 packets have the other side send 10 packets that are replies. So you're both sending the replies and the requests simultaneously so that the firewall will just happen. You know, it's, it's like a timing. It's a timing attack in essence, but it's a feature, not a bug, right?
 
Kyle Simpson:
Yeah, I think this is way beyond the depth of what we should get to on this podcast. You bring up very interesting points that are part of the design and the research and the analysis that we've done, but we probably should take those to our discord
 
Charles Max Wood:
Yeah, I'm
 
Kyle Simpson:
channel
 
Charles Max Wood:
gonna grab
 
Kyle Simpson:
and
 
Charles Max Wood:
the
 
Kyle Simpson:
to
 
Charles Max Wood:
wheel
 
Kyle Simpson:
dig
 
Charles Max Wood:
now.
 
Kyle Simpson:
into the more
 
Charles Max Wood:
So here's the, cause I find the peer to peer, P2P, I love the discussion, right? What can I do with it? What can't I do with it? You know, how do I make this work and be a good citizen? You know, and make all this go. But I have to say, I mean, one thing that I'm just wondering about as we dive into this is, you know, how do I build these apps? Right? Because you've kind of said you build it with web technologies. I actually went and looked at the guide and the guide says I can use React, Svelte, Tonic. I don't know what Tonic is. Uh, vanilla and view. And I'm assuming vanilla is just HTML and CSS and whatever JavaScript thing you want to drop on it. Um, but yeah, I mean, is that it? Do I just, I'm assuming I just put all of my source code in a particular folder and I just write a web app. I mean, is that. Is that the reality of what we're talking about here?
 
Kyle Simpson:
Yeah, you literally build what we would traditionally consider to be a progressive web app with or
 
Charles Max Wood:
Okay.
 
Kyle Simpson:
without the service worker component of that PWA. But if you were building an installable app, an app that was designed to have an app like experience, not a website like experience, you build that with whatever web technology you like, we are runtime, uh, wraps around the native web view of each platform. We target all the platforms to target windows, Linux, Mac. iOS, Android and Chrome OS. So we use the native web view on each of those platforms. Our code normalizes the differences between those web views. And we load your app up into that web view. And then we inject into that web view, additional APIs that allow you through what's called IPC to communicate back secured with CSP headers, right? So you can just free range access. You can lock it down, but allows you to communicate back with the runtime. to have access to the full file system, the full networking, the full Bluetooth that we talked about.
 
Dan Shappir:
Yeah.
 
Kyle Simpson:
And so it's literally just a web app with some additional node-like APIs.
 
Dan Shappir:
I think that this is a key aspect when we are comparing to other technologies that are out there for building native applications using web technologies. A key difference, and again we discussed it in previous episodes, but the key distinction is that some of them use web technologies but the UI is still native, while others as you, basically the UI itself is web. It's like you said, it's a web view. So everything is... HTML effectively and the browser DOM. Enhanced with additional functionality but maybe normalized, like you said, across different implementations. But still, what you're building is a web app.
 
Kyle Simpson:
That's exactly correct. And actually
 
Charles Max Wood:
Okay.
 
Kyle Simpson:
when I joined socket, let me just emphasize when I joined socket literally on day one, I said, I would like us to eventually be able to do the same things that we're doing in a native app, but just bring those directly to a real PWA, not even a packaged thing in the app store, just a real PWA that somebody visits in a browser. I'd like them to have socket like capabilities and there are on the roadmap. some explorations around that with some tricks of a specialized service worker that can kind of intercept and communicate in a backend way. So, but that, I just wanted to disclose it is my goal that eventually we don't have to use the native app wrappers to achieve this. I think the web can do this. Where I look at it as using the native app wrapper as a temporary stop gap until the web has this capability to communicate peer to peer the way it always should have been able to communicate.
 
Dan Shappir:
So yeah,
 
Charles Max Wood:
I hope you're right, to be honest.
 
Dan Shappir:
so the
 
Charles Max Wood:
This
 
Dan Shappir:
motive,
 
Charles Max Wood:
is something that becomes web-mangive.
 
Dan Shappir:
yeah,
 
Charles Max Wood:
Anyway, go ahead, Dan.
 
Dan Shappir:
yeah, so this is the feeling that I got from listening to you with the explanation. Even though you started with the native app angle, because that's the easier one to understand, at the end of the day, what's really driving the entire concept is that peer-to-peer facet. At least that's the vibe that I'm getting. and that the need for the native app stems from current limitations of the web platform that makes it difficult to integrate that this peer-to-peer protocol into the existing infrastructure.
 
Kyle Simpson:
I am speaking as a, as an individual person. When I say that I'm not speaking for the rest of the members of my company, but it's why I joined socket is because I believe socket is an effective stop gap while the web upgrades and trains all of the web's users to think like this, to own their own data, to own the responsibility. That's actually what's driving me even more than like let's reduce cloud costs, which I think is going to be compelling to businesses. To me, what's driving my involvement in socket and why I think socket is going to change the web is because we have already seen over the last five to eight years, a pretty significant change in user web user behavior around authentication. We now see in large swaths of the web. We now see people embracing this concept of two factor authentication because we have trained little by little over many, many years. a lot of the users of the web to own the responsibility for providing a more secure authentication process. And that typically has involved having a second factory, second, generally a second device. That's an ongoing process. We certainly haven't upgraded everybody to that way of thinking, but we've seen a wide shift in that behavior from over the last five to eight years. We need to take the same shift, the same kind of shift for people's relationship to their data. Right now, our perception is my data is not my responsibility and it's also not my property. My data is actually owned by the cloud. It's owned by the business and it's not my responsibility. It's their responsibility and we need to completely flip that to where users expect that data is first and foremost on their device. Their data is on their device so that even if they're not connected to the internet, They have their data and a, we also need to help them realize that it's their responsibility to make sure that their data goes only where they want it to go. Nowhere else. So we'll make it extremely easy again, by providing things like Bluetooth and so far, we're going to make it easy for you to synchronize all of your data across all of your D all of your devices. Apps will be able to do that in the background. And so you'll get the benefits of synchronization without needing a cloud. server to do it. And once we train users to expect that, they will, I believe, begin to choose apps that give them that control over their data. It's becoming increasingly, especially in certain parts of the world, an increasingly important conversation about what happens when my data is used in ways that I don't like. We see loss of freedoms here in the United States based on them being able to use your data in ways and There are certainly other countries that have these problems as well. So I think we're seeing that shift in user perspective and in behavior, and it will take many more years to get there. But I think over the next five to 10 years, that will happen. And that's why I said at the very outset that I consider this to be an inevitable change to the web, because not only will businesses go where they can get the same or better experience for less money, that is a proven principle of commerce. But also I think users will vote by choosing things that put them back in control. That's why I'm at socket.
 
Charles Max Wood:
All right, so I've got a couple of things that I wanted to
 
Dan Shappir:
Thank
 
Charles Max Wood:
ask.
 
Dan Shappir:
you.
 
Charles Max Wood:
One of the first ones was, and I think this is probably gonna be a fairly straightforward answer because I'm still looking at the guide here. But in order to get all of the extras that you're talking about, the networking, the Bluetooth, the, you know, some of the other features that you've brought up, it looks like it's as simple as just doing an NPM install and then importing the library. And then from there I can call the APIs. Is that correct?
 
Kyle Simpson:
It is, you do need to understand that to experience those APIs, in other words, to run them, you actually need to be building an
 
Charles Max Wood:
You have
 
Kyle Simpson:
app
 
Charles Max Wood:
to build
 
Kyle Simpson:
in
 
Charles Max Wood:
an
 
Kyle Simpson:
like
 
Charles Max Wood:
app,
 
Kyle Simpson:
the local
 
Charles Max Wood:
yeah.
 
Kyle Simpson:
app emulator, right? So it's, it's not going to run in a web browser because the browser
 
Charles Max Wood:
Right.
 
Kyle Simpson:
doesn't have these capabilities yet, but yes, it literally is take your PWA and drop it in a folder NPM install, and then you're running an emulator and you can refresh the page just like you would refresh a browser page, but now you're refreshing an actual app.
 
Charles Max Wood:
Right. One other thing I'm just gonna throw in here, we had an iOS show for a long time. I may bring it back at some point, but one of the things that people always ran into was generating the certificates for the apps. And I love that you have a walkthrough for it. So just
 
Dan Shappir:
Thanks for
 
Charles Max Wood:
props
 
Dan Shappir:
watching.
 
Kyle Simpson:
Mm-hmm.
 
Dan Shappir:
Bye.
 
Charles Max Wood:
on that, because it is a giant pain for Apple apps.
 
Kyle Simpson:
It is.
 
Charles Max Wood:
So the other question that I had was, you mentioned that some of the capabilities you believe can, you know, be built into the browser. Are you all working through the process of, for example, submitting these to the ECMAScript committee, TC39 to see if they will accept some of these? And then the other question I have is, what are you gonna do about Safari when it's still way behind? And still way behind, and still further behind.
 
Kyle Simpson:
Yeah, right. So first off, this won't be TC 39 because these are not JavaScript features that are needed. These are web app web platform features.
 
Charles Max Wood:
Oh,
 
Kyle Simpson:
So
 
Charles Max Wood:
okay.
 
Kyle Simpson:
it'll be what
 
Charles Max Wood:
So
 
Kyle Simpson:
wig
 
Charles Max Wood:
you're going
 
Kyle Simpson:
and
 
Charles Max Wood:
to
 
Kyle Simpson:
W3C
 
Charles Max Wood:
put it through
 
Kyle Simpson:
that
 
Charles Max Wood:
someone
 
Kyle Simpson:
we will
 
Charles Max Wood:
else.
 
Kyle Simpson:
have to petition.
 
Charles Max Wood:
Yeah.
 
Kyle Simpson:
Right. But that's absolutely on our roadmap to petition those things. I think we need to wait for a little bit more maturity in the web transport spec because it is the closest that we've seen come to by some, by virtue of the fact that it finally embraces UDP for the first time. Um, they're still not where they need to be with that. And so I think you'll see us advocate for extensions to web transport because that's already in process and likely going to happen. Who knows how long it takes. That could take many, many years. So in the interim, we're going to put most of our effort into making our runtime allow that. But I do, I do absolutely expect, especially for myself, my own advocacy to be trying to push on the standards to say, why do we need a native rapper? to give us this UDP capability when an installed PWA could have that. So you could, you could give those capabilities to web applications and only turn them on for an app that's been installed. And that gives the same level of like assurance to a user as just downloading a random app from, you know, the Google play store for example.
 
Dan Shappir:
By the way, you might want to talk with the winter CG group as well. I mean, you know, having the different run times on the different platforms that that looks really relevant, especially since a lot of them really can't be stateful and therefore can't use a protocol like TCP.
 
Kyle Simpson:
Right. Yeah. We actually have one of our, one of our employees is going to the winter CG meetings.
 
Dan Shappir:
Oh, excellent.
 
Kyle Simpson:
So we're going to be advocating there as well. I'll also throw a shout out another, uh, one of the communities that we are part of and really trying to bolster is the local first web development community, local first web.dev is their website. There's a discord community that they have up that they have monthly meetings. I'm actually speaking at the, um, at the end of this month of may at their local first meetup. Um, But this community is full of all of the big players in this space of local first and peer to peer and the driving of the web to move to these different models, all the like forward thinking companies that have been doing this for years, like Inc and switch and some of those others and socket, you know, being newer to the, we just joined this community and are trying to bolster and support that. So I want to shout out local first web dev because the, I think the people that are going to make this change for the web are the people that are in that.
 
Charles Max Wood:
Nice. All right, well, we're getting toward the end of our time. I'm sorry I grabbed the wheel, but I just wanted people to be able to find this stuff. By the way, where I looked and found the guides was socketsupply.co slash guides. And it, I mean, I'm looking through it and I'm going, yeah, this all makes sense to me and it's fairly easy to get going. So I'm kind of tempted to do some videos and kind of show it off, but
 
Kyle Simpson:
That'd be
 
Charles Max Wood:
we'll
 
Kyle Simpson:
awesome.
 
Charles Max Wood:
see how much time I have over the next few weeks. So.
 
Kyle Simpson:
We've got, we've got active users in our discord community. So I'd invite anyone that listens to this to come
 
Charles Max Wood:
Oh, nice.
 
Kyle Simpson:
check it out on that website and then come to our discord community and we're active there. And we've got a bunch of other users that are building stuff. We've already got businesses that have started doing the conversion process. And I'm sure they'll report back on what works and what doesn't for them. But this is all it's, this is not like this. We hope this happens in the future. It's all happening right now. And we're excited.
 
Charles Max Wood:
Yeah, well, that's
 
AJ O’NEAL:
So
 
Charles Max Wood:
the
 
AJ O’NEAL:
one.
 
Charles Max Wood:
great thing I think about the ecosystem out there is that you can go and try stuff, right? So you all at Socket Supply can push this forward in your way. Other people may innovate something else and then we wind up with something that's really cool and way better. So yeah.
 
AJ O’NEAL:
One
 
Charles Max Wood:
All right.
 
AJ O’NEAL:
last
 
Charles Max Wood:
Let's...
 
AJ O’NEAL:
question I have. Is IPv6 going to be our savior? Yes or no?
 
Kyle Simpson:
Um, actually, uh, the nat traversal of IPV six is terrible. So no, uh,
 
AJ O’NEAL:
Okay.
 
Kyle Simpson:
it's, it's not at least not as far as what we're talking about with UDP based peer to peer.
 
AJ O’NEAL:
Okay,
 
Kyle Simpson:
It's not
 
AJ O’NEAL:
let's
 
Kyle Simpson:
going to
 
AJ O’NEAL:
just
 
Kyle Simpson:
work.
 
AJ O’NEAL:
stick
 
Kyle Simpson:
Um,
 
AJ O’NEAL:
it to the
 
Kyle Simpson:
so
 
AJ O’NEAL:
IPv6 hopefuls and let them know there's no chance.
 
Kyle Simpson:
no, I'm calling it right now.
 
AJ O’NEAL:
Okay, I'll call it
 
Charles Max Wood:
Alright.
 
AJ O’NEAL:
with you for different reasons.
 
Charles Max Wood:
All right, let's go ahead and do some picks. I think we tried doing the self promo thing for a while. I'm just gonna let people roll them into their picks. AJ, what are your picks?
 
AJ O’NEAL:
All right, so I think I may have already picked this, but there's this salt. It's like a Gatorade type of thing. And I wouldn't recommend it for the health benefit or anything, but it just kind of tastes good. It's called LMNT element. And I've ranked the flavors. Hold on one second. I'm gonna bring up my ranking of the flavors.
 
Dan Shappir:
Hahaha
 
AJ O’NEAL:
Number one, I'm gonna pick raspberry. which I don't know how they make it work, but they do. And then citrus is number two. After that, orange followed by mango chili. And to get the mango flavor, because your taste buds exist all around your tongue. And in order to get the mango flavor, you have to let it get to the sides of your tongue. If you just swig something, you'll kind of create a channel of your tongue and the water will just go right over your tongue and it won't get over to the side. So you're gonna have to. have to swish it to get the full mango flavor but it's there. And then and then we get to the ones that don't that that I would say aren't good. There's watermelon which if you like watermelon things I guess you'd like it but watermelon is generally a bad flavor. Then chocolate which is I think it could grow on me that's actually I have that listed as tied with watermelon because they're that neither one of them I would say are good but I think chocolate I liked it less, but I think it has more potential to grow on me than the watermelon. Then Libin lemon habanero. That one's just hard to drink because it's it's mostly heat. And then after that is raw, which is just the salt flavors. And that one ranks last for me because it tastes like sweat and tears, cold sweat and tears too,
 
Dan Shappir:
Hahaha
 
AJ O’NEAL:
which is even a little bit more
 
Charles Max Wood:
Hehehehehe
 
AJ O’NEAL:
uncanny
 
Dan Shappir:
How
 
AJ O’NEAL:
valley.
 
Dan Shappir:
about licorice?
 
Kyle Simpson:
the
 
AJ O’NEAL:
I don't I don't know that they came out with one that's grapefruit and I haven't tried it I'd imagine that it would probably be okay something that they use for artificial sweeteners You'll notice that all all artificially sweetened drinks Tend towards a citrus flavor. I think it masks some of the bitterness or some of the strangeness of the artificial fleet sweeteners, but anyway, it's There they're kind of expensive. You have to buy a set for 40 bucks and then And there's only 30 in there. So it's a dollar 30 a piece. So it's quite a bit more expensive than than the good old Mountain Dew. But it's it's interesting. It's it's interesting. Again, I'm I'm not going to claim, you know, that you're actually going to get any health benefit from it. But maybe drinking salt is better than drinking sugar. I don't know. But it definitely tastes a lot better than you would expect when I say it's a salt mix, an orange flavored salt mix. You might think. Uh, no, I couldn't do that, but it actually, it works out amazingly well. So I'm going to throw that out there. And then of course, tears of the kingdom. I, I do have to say the first few hours, it does feel kind of like breath of the wild challenge pack three. It doesn't, it doesn't really start to feel like its own game until you probably do the first two objectives in Hyrule. Then it starts to feel like its own game. Then it really starts to come on in its own, but I really was not Oh and don't watch any of the trailers if you can avoid it because that they that's one of things that makes the first few hours of the game tedious is trailer one basically spoils everything that you're going to do in the first. I don't know three to five hours of the game, which you know that kind of kind of stinks. But anyway, Tears of the Kingdom is I I'm giving it a thumbs up. It does give me anxiety. The map is at least twice as large as Breath of the Wild. So
 
Charles Max Wood:
Oh, wow. Ha ha
 
AJ O’NEAL:
if you have
 
Charles Max Wood:
ha.
 
Kyle Simpson:
Cheers.
 
AJ O’NEAL:
any completionist left in you, you need to
 
Kyle Simpson:
Oh god.
 
AJ O’NEAL:
beat it out. Just beat it out.
 
Dan Shappir:
Well, that's a good thing, isn't it? The ideal is to have a totally open world, isn't it, or something like that? I can imagine people using socket, what's the full name?
 
Charles Max Wood:
Socket
 
Kyle Simpson:
Socket
 
Charles Max Wood:
supply.
 
Kyle Simpson:
supply.
 
Dan Shappir:
Socket supply to build these open-ended multi-user games, free world, whatever. That might
 
Charles Max Wood:
Oh, that
 
Dan Shappir:
be.
 
Charles Max Wood:
would be interesting, right? You cross the border into AJ Land and then you're pulling packets from him and whoever else has played it and then, don't get me started.
 
Dan Shappir:
Hahaha!
 
AJ O’NEAL:
I don't know, but I can say that I appreciate the fan service. I think that they recognize that a lot of people felt that Breath of the Wild was a bridge too far. And they this one does feel a lot more like a Zelda greatest hits because you've got the Twilight motifs. You've got the skyward motifs. You've got the ocarina motifs. One thing that I will spoil ever so slightly. ever so slightly, there
 
Charles Max Wood:
La la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la la
 
AJ O’NEAL:
are grottos. There are grottos. So, and there's a lot of our old favorites from Link to the Past on. I don't know if I've noticed anything that goes previous to Link to the Past, but there's just a ton of fan service in this game that I appreciate, and there's a lot of little nuanced details that... could have been released as an update to Breath of the Wild, some of the menu system changes, a few of the interactions that you have with characters that have been tweaked just a little bit in ways that people kind of complained about that they fixed. So it's shaping up to be a really, really strong title. And I will say once you play the first few hours, you should immediately play them again, because there's a whole bunch of stuff that happens right at the beginning. that if you aren't looking for the details, if you don't have the scope of like the world that's being built, you'll miss just a ton of the detail of what's going on, especially in the opening sequence that is really interesting to see a second time. So I'm already doing, I'm playing it twice simultaneously, once that I'm streaming, which is on AJ Plays Nintendo. Uh, the Twitch and YouTube, and then another that I'm, I'm doing with my family. So I'm playing it twice simultaneously. Um, but yeah, so that's those, those are my picks. And then, uh, I will say being an A is coming together. I think we had some issues, both there were some personal issues, uh, some, some family things that came up for one of the guys as well as getting sick. So we did not actually get the servers in. two weekends ago, like we thought we would, but it looks like this weekend, we will get the servers up, everything's configured locally, so we're ready to take it up to the data center and then start accepting some beta customers. So if you're interested in cloud services that are privately owned with pricing that scales economically, bnna.net.
 
Charles Max Wood:
Cool.
 
Dan Shappir:
Mm-hmm.
 
Charles Max Wood:
I usually cut, try and cut off the long rambles, but I selfishly wanted to hear about it because I want to play the video game. So, Dan, what are your picks?
 
Dan Shappir:
Okay, I also have a couple of pics. So at the time of this recording, we had a previous episode where we brought Dan Abramov on to talk about the React Server components. At the time that we were recording this, the first part has already come out. The second part is supposed to come out this week. So this kind of puts a timeframe for our listeners around when we're recording this. And Dan gave a talk after a long time, I eat this from giving any talks. at RemixConf, which is kind of interesting because Remix is the React platform that's not currently embracing React Server Components. But anyway, this talk is really interesting because Dan is really trying to put a different spin on this whole concept. I think one of the big issues that anybody looking at React Server Components contends with is the break that it makes with... how React is currently used, seen, perceived, and understood. It kind of puts React on its head in a way. And in this talk, Dan kind of embraced that. So he basically gave the motivation, like started building React as a back end framework, effectively a JavaScript alternative to PHP, as it were. and then built from there. Like we said, it's an alternate reality where instead of PHP, people had JavaScript before the web existed and they decided to use that to build their backends before even frontends existed. And it's just all done with React Server Components. And it's a really interesting spin when it's presented this way because that's effectively, first of all, how they think about it. And it also puts a lot of their architectural decisions in perspective of why they chose the different things that you know, the different mechanism Various mechanisms that they chose so I I obviously highly recommend listening to our podcast every Episodes with Dan, but I also recommend watching this video. So it's called React from another dimension. So that's my first pick. My second pick is the podcast one that I had a bit of input on when it started. And I'm really glad to see it, like, you know, collecting more episodes and becoming a really interesting source of information. And it's called Catching Up with Web Performance. And it's kind of reminiscent of my JavaScript story podcast that you used to have, Chuck. but it focuses on people in the web performance community. So he's talking to people like Annie Sullivan that we had on this podcast, and other people, Barry Pollard, which we should have on this podcast. I think I might have invited him. Norm Rosenthal, who we had on this podcast, and others in the web performance community, how they got into web performance, where they came from, what they did in the past, et cetera. Really interesting. I'm enjoying listening to this podcast. So that would be my second pick. My third pick also has to do with previous episodes that we had. Remember, Ajay, when we had Joav Awami from Wix talking about the Wix platform for web developers, and you kind of pushed back on your desire not to be tied. to the Wix platform. And interestingly, Wix have recently announced Wix Headless, which is basically providing all of their services as headless services or APIs that you can use from effectively wherever. And they also have some sort of cooperation going on with Netlify. So you can actually, if you're building or deploying on the Netlify platform, let's say you're building something in Next.js or whatever, and you're deploying it over Netlify, you can very easily integrate with a lot of the various Wix back-end services, like Wix Booking, and Wix Events, and Wix Payments, and so on and so forth. There's a whole bunch of them. I haven't tried it myself, but it sounds really interesting. So that's another pick. Probably need to get somebody from Wix or Netlify or both to come on and talk about that And my last and final pick I used to pick the war in Ukraine and then I kind of stopped I don't know why maybe because it's just going on for so long. We're kind of normalizing it but Russians really Russia recently announced that they have captured the Bahamut Ukraine kind of denies it or at least partially denies it, but the point here is that Russia has effectively leveled Bakhmut. So you're talking about a city that has existed, I think for centuries, was home for tens of thousands if not hundreds of thousands of people, and is now a big pile of rubble. Nothing more. And this war is so atrocious and it's so sad and heartbreaking. And again, I call on anybody who can have any way of helping the people of Ukraine to do so. And that would be my last pick for today.
 
Charles Max Wood:
Cool, I'm going to jump in with a few picks here. So the first one is I do a board game pick. I haven't played any new board games just because my friends and I usually get together and play. It's like the last two weeks of school, and so we've all had stuff going on. So I'm just going to fall back on one of my favorites and just pick one that I've already picked. And the one I'm going to pick is called Arc Nova. It's kind of a complicated, uh, involved, uh, zoo games. You're building a zoo, you get animals in, they give you different abilities or things like that. And so you're trying to build the prestige and, um, other parts of your zoo. And then, um, right at the end, it's basically. You know, down to who built the best zoo takes about two hours, maybe a little longer to play. And, uh, anyway, I. I still, I really, really, really enjoy it. So, Board Game Geek has it ranked at a 3.75 weight, which is fairly complicated game, fairly involved game. So if you're a casual gamer and you don't like the really, really involved games, this is not your game. If you really love kind of the involved fun, in my opinion, fun, I guess, games, then definitely check it out. A few other picks, I just finished a book series. The first book is called I Am Not a Serial Killer and I just found out that there's a movie that's based on the first book. I haven't seen it yet because I just figured that out today. But the books are really good. They're relatively quick. I listen to them on Audible quick listens, I mean six, seven hours. But they're really, really good books and I really enjoyed them. The author is Dan Wells. And so I'll put links to those in the show notes as well. Um, and then yeah, the book club, I'm going to pick our book club book. Uh, the last, uh, call that we had last week, we actually had the author come and talk to us. Um, we're reading seven languages in seven weeks by Bruce Tate. Um, now Bruce, Bruce is a friend of mine, so he just, you know, jumped on. He's also going to come on for the last language, which I believe is Haskell. Um, but he's going to come on and we, you know, we can kind of dig into Haskell or whatever other questions we have reading the book. He starts with Ruby and then kind of goes more and more kind of functional concurrent with each language. So he does IO and Prologue and Erlang and Scala and Haskell and Ruby, those are the seven. So anyway, it's gonna be fun. It's gonna be super fun. So that's what we're doing through the end of June. And then the last thing that I'm going to pick, I'm just going to throw it out there. Um, I'm starting to put content together for top end devs that, you know, is all behind the paywall. And so, um, I'm just, I'm going to be handing out coupon codes at JS nation. But if you want to get in and get your first month free on top end devs, while I'm kind of getting things up and running and getting all this stuff put together, you can do that. Just go to top end devs.com, uh, slash sign up. And then from there. Use the coupon code JSJABBER and it'll get you your first month free. One other thing I did put together, a developer career momentum podcast that you can also get for free. Just go to topindefs.com on the front page. There's a form. If you fill it in, if you put your email address in, you'll get like an eight episode podcast that just walks you through kind of the ideas behind building your skills, building your personal brand, and building your network. so that you can advance your career. And yeah, those are my picks. Kyle, what are your picks?
 
Kyle Simpson:
Um, all right. I've got two quick ones. First of all, I went to a little concert at a venue here in town, uh, the other night. And the opener was actually my favorite act. The main act he was great too, but the opener, I wanted to call her out. She's a local Austin musician, Natalie price. So if you go to Nat price music.com, um, she just, she's a singer, songwriter, writes all her own songs and she was really like, uh, it was. emotional and vulnerable and really fun and enjoyable music. So, um, I'll call that out. And then the other one is, uh, just yesterday. In fact, I went out with a few thousand other people of my same name, literally names Kyle to a city
 
Charles Max Wood:
I heard about
 
Kyle Simpson:
here
 
Charles Max Wood:
that.
 
Kyle Simpson:
in Texas called Kyle, Texas, who was attempting for the fourth time to set a world record for
 
Dan Shappir:
Oh
 
Kyle Simpson:
the most number of people with the same name gathered in one location that The current record is six years old for the name Ivan in a city down in South America did it. And so for the fourth time, the city of Kyle, Texas tried to make that world record happen. We had over 1,800 of us that showed up named Kyle. That was unfortunately a bit short of the world record, but I'm proud that I was part
 
Dan Shappir:
What
 
Kyle Simpson:
of
 
Dan Shappir:
can
 
Kyle Simpson:
the
 
Dan Shappir:
I
 
Kyle Simpson:
effort
 
Dan Shappir:
tell
 
Kyle Simpson:
to
 
Dan Shappir:
you?
 
Kyle Simpson:
set
 
Dan Shappir:
And
 
Kyle Simpson:
the record.
 
Dan Shappir:
any, like, and I'm guessing certain cities in certain parts of the world, you know, take the cake easily with the name Muhammad. By far
 
Charles Max Wood:
Ha
 
Dan Shappir:
and
 
Charles Max Wood:
ha
 
Dan Shappir:
away more people than people named Kai, like certain cities in Indonesia or Malaysia or some places like that.
 
Kyle Simpson:
But none of them are trying to set the world record,
 
Dan Shappir:
Yeah,
 
Kyle Simpson:
so.
 
Dan Shappir:
but there are probably like hundreds of thousands of people with that name in those cities. Anyway.
 
Charles Max Wood:
Maybe. That sounds like
 
Dan Shappir:
It's
 
Charles Max Wood:
fun,
 
Dan Shappir:
the
 
Charles Max Wood:
that's
 
Dan Shappir:
most common
 
Charles Max Wood:
cool.
 
Dan Shappir:
name in the world. It's also the most common name, by the way, in Israel. It's the most common name, I think, in the UK.
 
Charles Max Wood:
interesting.
 
Dan Shappir:
Yep.
 
Charles Max Wood:
Cool! All right, well, thanks for coming, Kyle. I know we went a little over, but
 
Dan Shappir:
We always do. Ha ha ha
 
Charles Max Wood:
yeah, we'll
 
Dan Shappir:
ha.
 
Charles Max Wood:
wrap up here. Until next time, max out, folks.
 
Dan Shappir:
Bye!
 
AJ O’NEAL:
Adios!
Album Art
How to Build Peer-to-Peer Mobile and Desktop Apps with Socket Supply - JSJ 588
0:00
1:28:53
Playback Speed: