In a world of increasingly uncertain regulatory turbulence, many web3 apps have migrated either their frontends or even their whole application to IPFS. This provides users with better overall control over their experience. When using traditional centralized frontends like https://app.aave.com/, users are trusting the developers to serve the correct frontend. This can create negative events for users, such as what happened with the Uniswap delistings and the Miso hack.
While IPFS gives users a much greater amount of control over their experience, the current state of using IPFS amounts to collecting a bunch of CIDs for each application you use and storing them in a Google document, and often IPFS suffers from downtime and slow loading times.
To improve the situation, we’ve extended Homescreen to support all IPFS applications. You can test this out today by pasting any IPFS CID into the appfinder bar at the top of the Homescreen UI. Homescreen will be able to fetch the application and load it alongside your other applications. Depending on the file, the initial fetch may take up to a few minutes to load, but once the file is loaded it will be saved on Skynet so that it can be accessed quickly in the future.
This upgrade to Homescreen has been made possible by a series of upgrades that we’ve built into Skynet over the past few months. IPFS compatibility doesn’t just apply to Homescreen, any IPFS application can now be successfully loaded onto Skynet and will work natively, without requiring any code changes.
And the upgrades extend beyond IPFS. We’ve been working hard to support an increasingly wide set of familiar frameworks, including things like Gatsby and React. To the best of our knowledge, every application that is built using Gastby today will work with no changes when deployed to Skynet. This goes beyond even what is possible with IPFS. And better still, users have been reporting that Skynet provides better speeds, uptime, and reliability than centralized services like Netlify.
Following a similar idea, we’ve upgraded Skynet to fully support DNSLink. You can now host your applications and websites on Skynet, and point to them from traditional domain names, giving your users an experience that looks and feels like web2, but is actually getting the benefits of web3.
When we initially launched Skynet, we thought that supporting static website frameworks like Gatsby would be impossible. Even though Gatsby is a framework for static applications, it depends on tricks from the server to support things like 404 pages and error pages. And when we launched Skynet 2 years ago, we had no idea how to support those types of features.
But as we got started trying to support at least a subset of features, we realized that there were tools and tricks and workarounds we could employ to overcome what we had previously thought were limitations of being decentralized. At first progress was slow, but as we filled out our toolkit the challenges began to evaporate away.
Engineering often works like this. If you can’t strictly prove that something is impossible, it often ends up being almost trivial once you know the right solution. And though finding the right solution can take months or even years, once it is discovered it becomes a permanent part of the toolkit.
One of my favorite places to watch this principle in motion is within the video game speedrunning community. Take for example Super Mario 64. A casual player needs about 12 hours to beat the game for the first time. The world record completion time did not drop below 1 hour until 2003, a full 7 years after the game was released. And by 2008, twelve years into the life of the game, people had figured out how to complete the game in less than 10 minutes. Even today, 24 years into the life of the game, people are still finding new glitches and optimizations.
If you want to dip your toes into that world, some videos I would recommend watching the video about the world record progression of Super Mario 64 any% (pronounced “any percent”), the video about overcoming the barrier in The Wind Waker any%, and the video about beating a Super Mario 64 level without pressing the jump button.
You see plenty of examples of this outside of video games as well. A long running joke in computer science is to prove that various non-computers are actually Turing complete, which means that they can successfully perform any computation that a full computer can perform. Famous proofs include demonstrating that PowerPoint Presentations are Turing complete, Super Mario is Turing complete, and Magic the Gathering — yes, the card game — is Turing complete.
A more practical example of this is undersea cables, which are enormously expensive to deploy. Doubling the number of cables in the world today would cost hundreds of billions of dollars. Instead of laying new cables, engineers often focus on finding ways to pull more speed and throughput out of existing cables. Cable upgrades can often increase total capacity by as much as 10x without needing to change the cable itself.
This same type of engineering is alive and well in Skynet, and in the blockchain industry as a whole. Network protocols are expensive to establish and difficult to change, but by continuing to innovate within the existing constraints of a protocol you can massively improve the features available to users. Constraints that seemed oppressive and challenging just two years ago are now almost entirely irrelevant. And as the work continues, we expect that even more of the constraints on Skynet and the crypto scene today will disappear, lost as historic footnotes in the road to ubiquitous adoption.