On The Brink with Castle Island - Paolo Fragomeni (Socket Supply Co) on the Definition of web3 (EP.306)

Episode Date: April 13, 2022

Socket Supply Co founder and CEO Paolo Fragomeni joins the show to discuss what web3 is and isn't – and what it should be. In this episode:  Paolo's start writing modem software and BBS in the pre-modern web days  What delineated web 1.0 from web 2.0 The single request that really made web 2.0 possible  How today's web is limited by incumbents  When did web 3.0 really emerge? What distinguishes it from 2.0?  Best definitions of web3?  State of the web in terms of centralization and prospects from here  How the internet has flip flopped between centralization and decentralization  What will push users towards web3?  Moxie's comments on web3 and whether they have any merit  What Paolo is building at Socket Supply  Why p2p is so fundamental  How to get started with Socket Supply  Read about Socket Supply in Coindesk and on their website.  Intro/outro music: Ocarina #986 (used with permission) 

Hello and welcome back to On the Brink. My apologies for us having taken all of last week off. Please permit us one week per year of vacation. We are back. Today we're sitting now with Paolo Fragromeni, who is the founder and CEO of Socket Supply Company, a firm dedicated to building decentralized cloud computing tools for developers. They are announcing a $3.5 million seed round of funding.

which we Castle Island participated in. Today's conversation hinges on what Web3 is exactly. There's a lot of definitions floating around. Some people define it as a model where end users will actually own the internet platforms that they use. Some define it as a model where users will have more discretion over their identities and more control over their data. Palo has a bit of a different take. He's been around building peer-to-peer software since really,

before the internet existed in its current form. And he is a wealth of knowledge on the topic. Let's dive right into the episode. So I'm sitting down here with Paulo Fragamini, who is the CEO at Socket Supply Company. You guys are announcing round of financing today. So congrats. I think today we're going to mostly cover what Web 3 is and how socket supply fits into that. Palo, welcome to the show. Thanks for having me. Yeah, I think Web 3 is a little bit ambiguous for some people, and I feel like it's worth talking about it.

I don't think there's ever been a good definition for Web 3, so maybe we'll devise one today. But I want to rewind. I want to go all the way back, maybe not to the very beginning, but before the mainstream web. And so you were active back then before, you know, the consumer web was a thing. So tell me about your early days there. Yeah, I'm ancient in terms of internet years. Yeah, I was a web developer in the 90s. Yeah, before the web became

mainstream, I actually wrote modem software. And modems are what connect devices, still today. And I was interested in modems because of BBSs. And BBSs were basically the precursor to the web. A BBS is a bulletin board system. And it was basically a server. And people mostly ran these out of their homes. And there was tens of thousands of these. And basically, you'd find a phone book of

phone numbers and people would circulate these phone books of numbers and you would dial in and download files and software and you'd share code and send mail. They had federated systems of email before email existed really.

And it really was super interesting because it was a big part of how open source actually started. I mean this was the first place really where you find source code and socialize on it. Because it's the idea that before this distribution system existed, there was no way to really share source code?

I mean, I guess you could literally print it out and put it in libraries or something. Yeah. I mean, it was really the kind of first place that we saw people actually host code and start to talk about, oh, this is how this runs and, oh, there's an issue with it. But there was a lot of limitations to these types of systems. I mean, specifically, it was complicated. to you needed to understand how to use a terminal emulator and it was you could literally have only a few people or so in most cases only one person dial in at a time um to the bulletin board

yeah so concurrency was terrible right there was no it's like a bulletin board but only one person can look at it at a single time yeah exactly yeah yeah i can see how that would be an issue um what was the what was the breakthrough that graduated us to sort of the web? Yeah. Well, so really Web 1.0 was it was really a success story about concurrency and also about user experience. And so coming from really super popular technology like BBSs, The web and really the protocols that enabled it were, you know, they were highly concurrent. So you had a lot of people able to connect to a system and get information from it because it was request response oriented, right, over HTTP.

You know, and a connection was only required for, you know, the request response life cycle, you know, instead of the whole duration. So ultimately it kind of behaved more like a sort of a postal system, right, where packets were routed over TCP IP. And it was really just much simpler in terms of how you looked at a website. You know, 1.0 was really like this great breakthrough of user experience, right? because you were looking at documents, and it made it really easy to do that. But the problem at the same time was that it was really just designed for linking documents. Just returning to the, actually, the BPS for a second,

do you see the symmetry between that very federated kind of, you know, everyone running their own server model and where we might be returning to now in terms of restoring that like topology kind of thing? Yeah, I think, you know, we've definitely, there's a sort of cyclical nature to some of these themes. And, you know, it starts by, you know, one area improving and one area, you know, becoming obsolete. And it's really a living, organic thing.

thing, what we're doing. You know, I mean, it's important to think about the web as really like an organically grown living thing. Yeah, because, you know, web 1.0 was great. And then, you know, people got excited and they started making innovations in it. And really, you know, we went to Web 2 because, you know, people made improvements. people made breakthroughs. And inarguably, the Web 2.0, the moment that it really became Web 2.0 was an innovation, small innovation, really small innovation, called XMLHTTP Request API. And this was super interesting, actually.

This was, so instead of refreshing a page, which is what you do. did with the browser during Web 1.0, you could actually request data in the background, and you could keep the page as it was. And so this allowed people to build things like Google Maps and Gmail. And actually, the API was originally created by the Outlook team at Microsoft. So Microsoft was really instrumental in Web 2.0. And then from there, SaaS was born. Really, you had software as a service at that point. Right. And then the web, was able to start competing with desktop software. But no one called it Web 1.0 or Web 2.0 at the time, right?

Yeah, I mean, it's really Web 1.0 is kind of like a retrospective thing. I mean, after, it usually takes a while for the technology to actually become established and then people say, oh, that was Web 1.0 or that was Web 2.0. But really, both of those two milestones had very highly identifiable breakthrough things that you could point to specifically. Even though it wasn't the case that people were necessarily using Web 1.0 and 2.0 to actually describe the web. there were these clear thresholds and delineating moments when looking with the benefit of hindsight, we can say there was a transition. Yeah, absolutely.

And during these times, you know, when you're in the middle of it, there's a lot of people who are skeptical or a lot of people who are, you know, vehemently against some kind of new technology for whatever reasons. But ultimately, like, you know, history kind of tells us what happened in the short history of the web. So everyone likes to hate on, I guess, the default web, Web 2.0, which I don't know, when would you say 2.0 began in the early 2000s, late 90s? Yeah, I mean, really Web 2.0, like I said, was about the XML HTTP requirement. request API, right? And I think objectively, you know, that was it because it transformed how people built things. Before, you know, before Google Maps, Gmail, you know, Outlook, things like

that, you were really just looking at documents and linking them together. But, you know, like as a result of that, you know, the web that we know at this point, which were, we're still really in the kind of midst of this web 2.0. It's incredibly complex, and we're sitting on top of like a mountain of technical debt. And this is really where the problem with Web 2.0 lies. Browsers are among probably the most complicated code bases in the world. and it's not necessarily because of the core web technologies like HTML, CSS, or JavaScript. And it's also really difficult to introduce significant features and get vendor consensus

because browser vendors whose core business is ad click-throughs, they're not incentivized to create the best web. they're kind of incentivized to create a web that's ideal for their business. And similarly to, you know, incumbents like AWS or Google Club, they're incentivized to advocate client server systems designs. And, you know, we end up, for all this stuff, we end up bending over backwards to kind of accommodate this design, which really, kind of puts us, like I said, under this mountain of technical debt.

And the complexity, this debt, it's really compounding. And I think it's inhibiting growth. So we're kind of here at, I think, peak Web 2.0. We've hit that threshold. And there's a tipping point, sort of. And so a lot of people can point to sort of like political and social consequences of the client server model of the fact that Internet, that infrastructure is so centralized,

and there's just a small handful of firms that ultimately have discretion over the nature of the internet and who gets platformed and things like that. Would you say that it's a technological reason that we have this model that it's so dominant and that the internet is so centralized, or is it more economical, as you sort of imply here? Well, it's, you know, like I always think of this as,

as the internet is this organic thing that's pushed and pulled by different people with different objectives, with different businesses, different incentives. So it's maybe a little of everything. But I think in that, people are trying to define what the next major version of the web is. And whatever it is, it's still emerging. What might be a useful way to define this is, like, trying to look at, you know,

what is the ethos of what people are looking forward to? Like, what are people, what do people want at this moment, given where we are. Right. Because I guess Web 1.0 was many people can read documents at the same time. And then Web 2.0 was users contribute data back to websites and it can be an interactive experience. So I guess the rubric could be what is it the Web 3 lets you do, let's users do? Yeah, I mean, people are definitely. asking exactly that. Is it crypto?

Is it P2P? Is it something else? So it's definitely a contentious term. And that's what you get when you have a lot of different stakeholders with different ideas. But it's great that it's actually contentious because it means that there's something worth discussing. In Web 3, like that term existed pre-cryptocurrency.

Am I right there? I feel like that term was batted around before cryptocurrency was actually a thing. Yeah, actually it was Berners-Lee, Tim Berners-Lee, who he actually had this idea of Web 3 kind of like really long time ago, and it sort of had a lot of different meaning. I was like not really what people are talking about now. But yeah, I think it's just it's, it's, it's, a result of a lot of people with a lot of different ideas. And really what we're looking for

in trying to have some objective criteria is like what is the consensus? Like what do most people care about? And I think like if we step back and we look at the big picture, there's two things that really stand out. And one, that's what we're seeing is a resurgence of, of interest in distributed systems, decentralization, and like symmetrical systems designs. What do you refer to with symmetrical systems? Right, so an asymmetrical system is like a client server, and a symmetrical system is sort of where like every node in a network is equally as important.

Right. So the first thing I think we're seeing is like I said, a broad resurgence of interest. and decentralized systems. And then I think, two, developers really want to build all of this with the web stack. When you look at the excitement around Web3, like, would you say that follows from the fact that there's this, you know, significant financial incentive and there is, you know, now direct monetization, you know, at the internet level. And because cryptocurrencies are built in this decentralized way,

that that sort of design philosophy is trickling over to internet applications, or is it just the case that cryptocurrency is something that's rather decentralized that is a component of this new resurgent interest in decentralization? But it's not necessarily the case that the excitement around Web3 flows south from crypto as a phenomenon? I think it goes both ways. I mean, I think that the concept of digital assets and new kinds of financial primitives are really appealing, given how badly our financial institutions have failed us.

I think that people are, you know, people are certainly looking at things that are experimental. some of them don't make sense. Some of them are super promising, but they're all kind of missing some really important, really low-level things that could make them successful if they had. I think, like, you know, you have all of these people really interested from kind of all areas about decentralization or distributed maybe hybrid systems designs, but not a lot of people are really able to deliver much. And the reason why we're all sort of stuck with SaaS products and we're not really delivering a lot on Web3 is really because developers are targeting browsers and browsers

don't provide the necessary network primitives for people to build the kinds of things that they want to. So we need a model that's not browser-based but still provides a high-quality P-to-P experience. Yeah, exactly. I mean, I think that, that, you know, we've, I mean, we've been here before kind of in some ways. I mean, in terms of where we are in centralization, like, it's probably pretty important to remember that we've sort of flip-flopped between centralized and decentralized systems, like, throughout the sort of history of, the short history of the Internet. you know in the 1960s and 70s you had these you know early computing was centralized because computers were physically massive and then and then you know in the 80s you had the

PC revolution which allowed anybody to share data was extremely decentralized and this is this is really you know towards the late 80s you started getting things like BBSs and that was completely decentralized. We had some notions of federation, but then, you know, with the 90s, with really the Web 2 era, you know, was a flip-flop again back to centralization with client server, right? It was a hard swing back to centralization where SaaS was introduced. And SaaS, I kind of feel like it's become this dark pattern in a way. Like, it's ideal for hiding IP, intellectual property.

I mean, it's, it hides bad behavior. Like, we don't know what people are doing with data. You know, it also hides bad code, like, you know, fake AI. You know, like these world leaders of, you know, artificial intelligence, who turns out their code is really just a bunch of if-l statements. But I think the thing, It's really kind of the big failure with client server is just how much infrastructure, the requirements for infrastructure are absolutely just absurd.

And the amount of people and expertise required, it's just untenable at this point, like how it's evolved. So, you know, after client server, then we flip-flopped again kind of back to decentralized because we because peer appeared really became and it exploded and a lot of people sort of forget this history that you know there were tons of networks it was massive piracy was huge like you had new teletwork you had lime wire you had Napster you had tons of like household brand names of like

these really amazing applications that were really just for pirating content And like, you know, copyright holders, they shit their pants. You know, stakeholders were literally just sweating bullets going like, oh, no. But then we did another flop or flip flop because people panicked, right? So then we had streaming, which was really kind of the answer to the prayers of these people who were just hemorrhaging, you know, their investments. And so this hard swing back to centralization was easily identifiable to Netflix, Spotify. And it's interesting. Like people paid for this stuff because it just had a better U.S.

They were like, oh, it's easy. So I'll pay for it. That's fine. I won't pirate it because, you know, it's just, I don't even think the risk really mattered to a lot of people. And also, I mean, it's just more convenient and probably also cheaper. to stream music on demand as opposed to saving the files and figuring out how to manage, you know, and store that over time.

You know, and I guess like also the emergence of ubiquitous bandwidth and, you know, self-funded also helps there. Right. Yeah. Yeah. So I think that that that's peaking right now. I think we're just about on the other side of that peak, really,

where we're seeing something like, we're really seeing something interesting driving the swing back to decentralization. And as the prices of computers, as hardware just goes down, they get more powerful. And there's at this point today, more compute and storage outside of the data center than in all data centers combined.

And, you know, we're creating more data faster than ever before. Round trips back to the data center, like, they're making less sense. Even if the latency is low, it doesn't matter. I mean, any amount of time. And like a really good example of this is like, you know, hard real time, right? These are like medical devices or their, or self-driving cars, things like this, like hard. real time. That's where like you really can't afford you can afford like on device latency at a maximum. And so yeah, so as more computing and storage gets pushed out to the edge, that's

where people want to use it. So I mean, data centers are still valuable, but more for things like supercomputing and whatever. And so, you know, I think that the biggest technical argument, for distributed and decentralized systems is really this growth, this supermassive growth that we're seeing. And it's really a technical argument, I think. I mean, there are certainly other arguments, but I think that the technical argument is very strong. So here's an interesting question, right? So edge computing, I think we definitely see that it's a thing. I mean, you know, what I keep thinking about is like these browsers where you outsource the compute to, you know, a third party, right?

Because you don't want to do it on your device because it overloads the device. And then, you know, like Google's, what is it, a gaming product where you outsource the rendering to, you know, a server farm somewhere, as opposed to, you know, having your own GPU, having your own gaming rig. So is the fact that, you know, bandwidth is cheap and everyone has, you know, quality connections, is that actually push things in the opposite direction from what you're describing here where our devices are just little interfaces and the compute happens somewhere else? Well, that was really kind of known as thin client. And so this had its era, Sun Microsystem.

This was really pushed for this, where all devices were dumb and everything goes back to the data center. And this kind of like consolidation or centralization actually never really worked out. It just turned out that customers wanted to have some agency over their data and over what was done with it. And so yeah, the sort of thin client or the dumb client kind of way of doing things with the sort of hub and spoke model just never really won. Although there's definitely still tendrils of that idea floating around. Yeah, well, there hasn't been eradicated. Yeah, I mean, there's really a strong argument for a data center. I mean, a data center does some really important things, right?

I mean, there's very few customers who are going to own supercomputers. And, you know, there's just, there's computing tasks that we absolutely want a data center for. But I think that there are certainly some things that are pushing users towards Web3. Do you see those as technological things or just like the natural flow of society where we have this centralization, decentralization? or is it a political thing like you can talk about Silicon Valley tech firms, you know, being deputized for political purposes. We even see it sort of like for military purposes now like where, you know, the vast majority of Western internet consumer businesses deplatformed Russians, for instance.

So, you know, what do you see as the driving force there? Yeah. Yeah, politicization and de-platforming are absolutely drivers. For consumers, but also companies, those are major things. And that's probably a whole series of podcasts. I think, like, for us, it's really, I mean, we really like seeing this from the perspective of technical problem about infrastructure. And infrastructure is like, it's a whole conversation, right?

I mean, it's like, it's all the supportive things that you need to build a thing, right? It's all the prerequisites of your actual goal. Like, if you want to drive cars, you need highway infrastructure, right? That means paving equipment or off ramps or overpasses or highway patrol and dispatch and There's all kinds of stuff that leads up to just having highways, right? So, you know, almost everybody's probably experienced some kind of poor highway conditions, right? Because, like, we build really terrible infrastructure that lasts. It's just sort of myopic, right?

We build infrastructure in America that lasts about 100 years, or often a lot less. And software infrastructure is really similar, right? it's just on a shorter timeline roughly you know continuing with this analogy I mean it's like the timeline that we build

software infrastructure to last is about the cycle of a single person's employment right which is about two years or less these days you know so you know like a civic engineer

a DevOps engineer comes in and they do a bunch of work and they connect 18 or, you know, 20, 30, you know, contemporary AWS pipes and, you know, Amazon is happy because now you're completely entrenched. Your business is absolutely dependent on it. And, you know, and like these 30 different things. I mean, it's like, you know, like most people who are good at AWS know maybe a handful of these things. And over time, combined it a bunch of different people who are combining all these things together. And, I mean, just turns into a tangled sort of mess. In best case, right, they document it. You know, maybe they use cloud formation

or something where you can create declarative infrastructure. But, you know, now you need to maintain. They need to pay for all these things. And, you know, they've got just this, a ton of moving parts, and it's compounding this complexity. And so there's a lot of risk and cost in relying on a fractal of like really complex, you know, completely opaque cloud infrastructure. And, you know, and then here's what's really interesting. Suddenly there's this emerging wealth of untapped hardware outside the data center. And it's starting to look pretty attractive.

What does the stranded compute and storage resource? What form does it take? Yeah, so when a consumer goes out and buys a computer or set-top box or iPad or any kind of device that's online for even just a small amount of time, this is where you come into the concept of cost sharing, right? So in Web 2.0, the company or the developer pays the entirety of the cost of something to be deployed. Where, you know, in the distributed model, what happens is you share the cost. So when I buy my device, that's me paying part of the cost. Right now with my software, I'm sharing some of the hosting.

Maybe I'm sharing some of the processing. and maybe I'm responsible for connecting being a part of a network. Even if I'm online for just a short amount of time, I'm contributing to creating a large network. So this is really interesting. Unfortunately, there aren't a lot of tools in this space for developers to leverage this new model. Would you say that Unleash,

stranded hardware is part of Web 3 or is that something a few sort of Web 3 enthusiastic people have realized is going to be part of the phenomenon here? Well, I think if you go back to the sort of roots of, you know, things like Napster, Limewire, you know, you see that engineers understood like there's a wealth of of hardware that can be participants in a network. And in aggregate, they create a reliable network. And so, you know, it's a different way of thinking. But yeah, I believe that a big part of Web 3 becoming a real thing

means appreciating some of the history of distributed systems decentralization. So there is this great, somewhat critical blog post about Web3 from OxyMoyland Spike, founder of Signal, which is interesting because he's sort of a crypto founder. It also contributed to crypto in both senses, I guess, also contributed to mobile coin. And so he's certainly not foreign to the crypto industry, that's for sure.

And, you know, he's basically evaluating the Web3 landscape. He made some very salient points. I mean, talking about NFTs in particular, the dependency on open sea, and, you know, whether NFTs are meaningfully sort of on-chain or whether they live off-chain, I thought, was really well said. And then the other main thing that I took away from it was people don't want to run servers really under any circumstances. And, you know, we had fleeting epics of people running their own servers back in the day. But, you know, I guess he was saying it's unrealistic for something that intends to go mainstream to incorporate a server running obligation into that.

So, I mean, what do you make of his critique and do you think he's right about this inherent unwillingness to run servers? So I'm a signal user and I think it's an incredibly good piece of software. And yeah, he does, he's, yeah, I mean, he's built a phenomenal company with superlative engineering team. And just, you know, broadly to set the stage, I mean, I think there's a lot of trial and error going on in Web 3. You know, however you define it. But that's the nature of all of this is it's a lot of trial and error. Some things we get right, some things we don't. But I think he's right that nobody wants to run servers.

But technically, people don't need to run servers. What we need are good peer-to-peer libraries, and we're getting them. Things like HyperSWorm, LibP, P-2P, these are like super popular ones right now. And then the way that I kind of see this is that people will run their devices and they shouldn't have to think about servers. I think that the software that we run that we expect to be connected should be light enough weight and should expect to be in a network where devices are infrequently online and where it's an unreliable environment.

And if we design around that, then that's the ethos of good peer-to-peer network design is that nobody really needs to run one node that's more important than the other. No one really needs a super expensive server, not unless they're doing, like I said, some kind of supercomputing. And the reality is as well that cloud is still going to exist. And peer-to-peer is going to coexist with the cloud. Servers are great for bootstrapping peer-to-peer networks. They're also great for fallbacks, like stun and turn the whole ice flow. And some networks might not be very popular, so they don't always have peers online. And that's where the data center comes in to play again.

But not all peers need to be super powerful, you know, or always online. Just listening in short bursts, I think, you know, like I said, forms these very large networks. So the server might be the wrong primitive here to think about P2. It might be too high of a requirement, but you can have P to P without everybody running their own server necessarily. Exactly, exactly. Every node in a network can have different capabilities. And what we need to be careful of, we want to design systems, is giving too much responsibility, or having too much reliance on a node,

having too much capability or too much bandwidth or too much time on CPU number crunching or whatever. So returning now to Web 3, if you consider Web 3 in its current state, it has a lot to do with sort of shared registries that anybody can read and write to and public. key infrastructures that you can use to authenticate and prove your identity to internet services, things like that. It doesn't seem to have a lot of P2B components in its current state. Would you agree with that? Well, I would say that all of these things are actually made possible by peer-to-peer. Crypto, any of these decentralized networks, peer-to-peer technologies are

fundamentally the basis for all of these things. And so, you know, I think also what's probably important is to see that peer-to-peer is really the more interesting part of cloud computing, even. Because, as I said, at this point, like, there's more hardware outside of the data center than there is inside it. So how does socket supply come into this? What is your approach? Well, I'm so glad you asked.

So yeah, so we're basically, we're helping to advance cloud computing beyond the data center. Really, I mean, what we've been talking about is our mission. I mean, we want everybody to be able to participate in the web. We want everybody to be able to build the web. And we think that the web should be everywhere. And there needs to be, developers need tools specifically to leverage some of this symmetrical design that is necessary. for this kind of development.

And where we decided we wanted to start was with cloud computing, because that's essentially where everybody is today. They understand how client server works, and platforms like AWS are really powerful. But they're also super complicated. So about a year ago, less than a year ago, We raised 3.5 million in seed, and we now have a product that we've launched. And getting here was really difficult, but there was really a lot of interesting things that we learned.

And so, yeah, we're ready to... to ship our product, which helps developers to start with things they know, and then incrementally introduce distributed systems into the things that they're building. So it's really low risk. I see a lot of people trying to, you know, throw developers into the fire with these web three things and i see developers really having a hard time understanding how to fit together their model of how their worldview of how development works with these new things and so we our product really is kind of about incrementally introducing uh distributed systems to

developers. And how does that improve or alter the developer experience? Well, we want it to be seamless. I mean, you know, we start with like I said, you know, cloud platform, cloud computing platforms like AWS because they're familiar. They're also pretty difficult for web developers. And we understand web developers. So we have tried to make the cloud platform trivial for most of their workflows. And then when I say, you know, incrementally introduce some of these distributed systems, I can give you an example of, you know, how we in particular built an app that uses peer-to-peer to like almost exponentially make the AWS experience

better. So there's with AWS there's a terrible developer feedback loop. And the developer feedback loop is where you write code, you run it, you see the result. And it's really incredibly important for developers that this loop is really short. So, you know, you know, you Sure. You can pipe together a bunch of AWS services. You could do WebSocket API Gateway with Route 53, create some certificates with ACM, set up some lambdas to talk to DynamoDB, to keep track of peers. And there's all these things that you could stand up

and pipe together. And eventually maybe you'd end up with, you know, a real-time logs. But we were like, okay, that's insane. No one wants to maintain that. That's totally out of scope for most people, like, building anything. We certainly don't want to maintain this. And so we came up with zero infrastructure requirement solution by using peer-to-peer.

So basically, like, we deploy software in the – in the Lambda extension, which becomes a peer, and that peer can pipe standard out and standard error directly back to the user that's connecting to it by hole punching. And so this gives us a real-time socket between the Lambda and the developer. And so they get immediate feedback, 100% real-time immediate feedback. And even Amazon doesn't deliver this. And so these are the kinds of things that we're using peer-to-peer for, and they objectively reduce the amount of infrastructure required.

They reduce the amount of cost, and they just make the developer experience a heck of a lot better. So what kind of users are you looking to attract with your new product? Well, right now we're releasing the alpha version of the, product and we're hoping that people kick the tires on it a bit because what we'd like to do is we'd like to open source the framework that we built to build this product. I think that there's developers could benefit a lot from building the same types of highly distributed software that we are. Our framework is, you know, we built it with the idea that, you know, we wanted to provide users with the ability to create peer-to-peer applications that were truly distributed using the web stack for mobile or for desktop and have a sort of seamless experience between those two things.

So we're hoping that, yeah, people will kick the tires a bit and then we'll open source it and we'll kind of help people to start building apps in the ecosystem. So if socket supply is wildly successful, what does the internet look like in five years time? Does it look any different? Yeah, I think that you're going to start to see companies who are building less consolidated, highly distributed, highly distributed. distributed applications that depend a lot less on, you know, really complex infrastructure. One of the things that Moxie talked about in his article that you mentioned was just the amount of complexity that it takes to run a lot of the applications that we're running today. And, you know, I see, you know, socket supply as helping developers to sort of break out of that

sort of arbitrary complexity that is the result of us just bending over backwards to accommodate this client server model of building the internet.

So how should listeners get started now that they've been inspired? Where would you direct them? Yeah, come join us on our Discord. It's socket supply. There's a link to our Discord.

And then also, you know, come talk to us on Twitter. My handle is Heepwolf, but, you know, it's socket supply. Is our Twitter account? And you just, like, you know, we're happy to engage with people and, like, discuss things. And we're also, you know, participating in the hypercore protocol discord. That's also a really interesting one to join. But yeah, I'm just, we're really. interested in just engaging with people and sharing ideas and yeah well this has been great palo

very exciting looking forward to giving a shot thanks for coming on today yeah absolutely thanks for having me