Hey Kyle, enjoyed the discussion, especially the stuff you're doing at socket supply.
I'm definitely a fan of decentralization. Building the decentralized internet is one of the main plot points of HBO's Silicon Valley, and even though it's comedy, it definitely resonated as a good idea.
In this decentralized model, how do you replicate some of the advantages of the cloud though? Redundancy, reliability, latency improvements from having multiple cloud regions? The decentralized social network example, that puts a huge amount of responsibility on the users, most of whom are not tech savvy, to maintain multiple backups of their data to prevent loss of say their photos, which is presently solved for them by having them backed up to icloud or Instagram or whatever.
I think in the silicon valley show, they built the decentralized internet by essentially making the entire p2p network a fault tolerant, redundant distributed data store. It would need some smart solutions for identity and access management, and it really needs massive buy-in from the population at large to work.
Hi Josh Stevens. It's very common for most people to have no professional reference point for this subject. P2P is not widely understood.
The fact is, the Cloud becomes more expensive and less reliable with growth. But the proliferation of hardware combined with modern network programming has made it possible to reduce usage of the cloud.
Redundancy, reliability, and latency are compelling reasons to move away from the Cloud and toward P2P.
Growth means adding SREs, performance, and devops engineers. And they will all end up adding solutions to support that growth. The solutions will have their own problems. Depending on how much growth we’re talking about, you’ll also be building and integrating bespoke solutions. Now you’re building and maintaining a secondary product that might not be within your core competency or even related to your business. Countless companies have built their own PaaS. You end up executing deep performance profiling exercises, creating flame graphs and emailing Brenden Gregg. With enough growth, you’ll implement optimizations that require you to think outside the box to address issues. You’ll accumulate legacy and debt. Key people will churn, new people will need to ramp up on something that if we’re lucky has some degree of specification. Whew. Now add up all the billable hours for Cloud and Staff.
With P2P, there is no standard, so it’s best to assume nothing about how it works unless you’re talking about a specific protocol. P2P can be an umbrella term for a lot of different things; symmetrical networking, distributed storage, and compute, etc. Most people have almost no reference point for P2P unless they worked on building telco networks or products like Skype.
Now someone clever with some experience might say, well, P2P is a distributed system! And distributed systems are complex! You should avoid building them! You’ll end up needing to email Leslie Lamport about TLA+! Let me remind those people, every single Cloud platform is highly complex, eventually consistent, distributed system.
With our protocol, there are exactly zero technical expectations from end users. No one needs to host anything, no one needs to configure anything. There is no one trying to drain your battery or monopolize your storage. More precisely, at Socket Supply, we’re concerned with infrastructure, not storage, and not compute. An analogy is that we create freeways, on-ramps and off-ramps, not parking lots and not rental properties.
That means that with Socket Runtime, a few lines of vanilla JavaScript, CSS and HTML will get you a native app that runs on any OS, desktop and mobile. A few more lines of JavaScript let you discover other peers and sync state data with them. It doesn’t require a monumental buy-in for it to work on part of our cooperative network design (and as I said, storage is a different problem domain). We make it possible to proxy and relay packets without the need for servers. Our documentation goes into this pretty deep. We provide performance models and citations for the papers that we borrowed ideas from. LinkedIn is a terrible venue for such a discussion. But if you’re interested in leveraging high performance, modern networking techniques to reduce your Cloud cost and complexity, you should consider digging into Socket Runtime a bit deeper.