Ask HN: What non-obvious tech/market may take off in the next few years?
Web 3&#x2F;Dweb minus the crypto built on IPFS (or something similar).<p>I believe many developers will soon come to realize that you don&#x27;t need a blockchain to build most decentralized applications. Products like like Google Docs, social networks, messaging app, etc don&#x27;t depend on a proof of stake, and we shouldn&#x27;t be running miners to power such simple operations. All these applications need isa decentralized form of message distribution and log storage paired with public-key cryptography in order to build a CRDT log. I understand why IPFS in itself at first glance often seems over-hyped, since it is essentially just a hyper-distributed caching layer. However, I highly recommend looking at technologies built on top of it like [OrbitDB](<a href="https:&#x2F;&#x2F;github.com&#x2F;orbitdb&#x2F;orbit-db" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;orbitdb&#x2F;orbit-db</a>) and [Textile](<a href="https:&#x2F;&#x2F;textile.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;textile.io&#x2F;</a>). When they work reliably, their API is as easy if not easier than other &quot;server-less&quot; products like Firebase or Parse to use. Once libraries like these become mature, I believe the way we build software will be flipped on its head within 10-15 years to be completely client focused with minimal backend infrastructure.<p>The main advantages I see are:<p>* Increased reliability. This allows developers to remove almost all of their centralized servers and rely instead on a common infrastructure and protocol.<p>* Much simpler codebases and infrastructure. You only need to write a frontend for most applications. Building on u&#x2F;searchableguy&#x27;s comment: I can see no&#x2F;low code tooling really taking off with decentralized-first applications, since there is no need to manage a complicated backend infrastructure with vendor lock-in.<p>* Real-time by default. Since IPFS databases run off of CRDT logs which rely on realtime syncing of new operations, they are benefit from immediate updates at all times – even when not connected to the main swarm out in the boonies.
* Offline-first by default.<p>* Cost&#x2F;resource efficiency. No technology is magical, but [this](<a href="https:&#x2F;&#x2F;withblue.ink&#x2F;2019&#x2F;03&#x2F;20&#x2F;hugo-and-ipfs-how-this-blog-works-and-scales.html" rel="nofollow">https:&#x2F;&#x2F;withblue.ink&#x2F;2019&#x2F;03&#x2F;20&#x2F;hugo-and-ipfs-how-this-blog-...</a>) article from March is an early real world demonstration of how well this technology works already.<p>* Transport agnostic. It&#x27;s completely feasible to have your watch, your phone, and your laptop have their IPFS nodes connected over Bluetooth, but never have to worry about if and how they&#x27;re connected together since IPFS takes care of handling that P2P connectivity automatically. Instead of writing code that says &quot;my watch created a reminder, upload this to the cloud for my laptop and also tell my phone this happened if we&#x27;re connected,&quot; I can just write &quot;my watch created a reminder, broadcast this operation to the IPFS network&quot; and your phone and laptop will automatically receive this update.<p>* Security. The less that is stored on centralized servers, the better. While OrbitDB is not built to work off an encrypted database yet (it&#x27;s in the roadmap for v1), Textile already is. Having everything be encrypted by default and optionally never leaving my device has many advantages.<p>The main challenges I see blocking this from going mainstream:<p>* Reliability still feels like the early days of the internet. The database-level libraries are still young, IPFS is slow&#x2F;unreliable at times, and browser support is fairly strong but still has a way to go, and native mobile&#x2F;native support is nonexistent.<p>* Filecoin is not ready yet. You still need to run your own IPFS node&#x2F;swarm in order to do anything serious. Existing pinning services can only go so far if you&#x27;re working with something like OrbitDB.<p>* Education. Security is of upmost important when designing technologies like this, so developers need to understand how a CRDT log works, how to build with merge conflicts in mind, and how to write&#x2F;manage custom ACL for complex interactions. It also takes a different way of thinking to design networks like this.<p>* Reliability and security audits.<p>* Transport protocols. At the moment, many of the advantages of P2P over things like Bluetooth have not been realized yet since the IPFS core is still where most of the development is focused at the moment.<p>* Cross-platform support. IPFS only has an official Go and JavaScript node implementation with a Rust implementation in the works. While Go has become fairly portable in recent years, it still has a very bloated runtime that doesn&#x27;t embed well on mobile and web. Once we have a reliable Rust port and some OrbitDB-like Rust-based libraries ports, I suspect we&#x27;ll start seeing ergonomic mobile and web APIs that bind to these popping up.<p>To be clear, I&#x27;m not saying centralized servers will vanish in to thin air. There are many tasks like indexing large amounts of data that are incredibly difficult and not beneficial to build on a distributed network. The decentralized web – if done right – will make developers&#x27; lives much easier for many common applications, but there should not be a need to port things that aren&#x27;t practical to run on the Dweb.<p>[Edit: Formatting]