The Myth of the Infrastructure Phase
usv.com
usv.com
What drives technology is stuff people want.
In that context apps are infrastructure too. I want to tell people something, so the app email helps me. And the infrastructure TCP/IP helps email. But from my perspective “I want to tell Dan the meeting changed” it’s all just infrastructure, a way to solve that problem.
The article implies that the infrastructure is like sitting there waiting for apps. But apps don’t just stroll along into the story. Apps come from needs.
People have a need for a way to send money for illegal stuff, and a need/desire for a medium of gambling. Crypto has risen to meet those needs.
Unless there are other demonstrated needs that blockchain solves there aren’t going to be more apps, or more anything.
> Unless there are other demonstrated needs that blockchain solves there aren’t going to be more apps, or more anything.
I agree with you that apps are driven by "needs". However, we should also keep in mind all needs aren't driven by rational cost analysis.
If a new technology potentially allows for a major shift of the centers of power and trust, then the needs are difficult to appreciate at first hand. Your needs may be different than someone else needs, a group's needs may be different that another group's needs, etc. Needs may conflicts, or it may happen that you don't understand some people's needs. We should take into account the interests of the actors of the system too.
We can imagine two currency systems, or two internets, coexisting together. What's matter is that everyone's needs are fulfilled, without one specific camp exploiting the others.
Diversity is a force, there is no reason to not let people claim or experiment with new ideas, as long as it's fair to everyone.
But I also think everyone is getting a bit tired of the marketing around crypto and blockchains. Yes it's probably useful, but no, it won't solve everyone's problems.
I hear this line often. As an aside, I'll just share some of the things I've seen so far.
1) International payments. There are countries where the domestic market isn't big enough, so once they expand, they quickly end up doing business with foreign companies, or hire people in foreign countries. Banks in different countries are unlikely to have a direct connection to each other. So they have to route through ones they do have a relationship--typically bigger banks. This process can take weeks, and can throw off the cadence of your people getting paid. Cryptocurrencies reduces international payments down from weeks to a couple minutes/hours.
2) Store of value in a country with runaway inflation. Venezuela has been the poster-child for this need, as its fiat has been inflating to the point where it's nearly worthless. The country doesn't allow people to leave, and makes it difficult to trade for other currencies. Hence, people there are using Bitcoin to store the value they have left.
3) Ownable and composable collectible card game assets. Cryptokitty is the poster child, but also check out Gods Unchained and Zombie Battleground. These are CCGs where the game makers can't nerf the cards you own. Not sure how they'd rebalance the game, but actually owning your digital stuff has emotional appeal to players. The other interesting thing here is that any game can build on top of these assets to make other games. That means you can move your digital stuff from game to game.
Just like the early internet, most of the early applications are for the ecosystem itself. Stablecoins, decentralized exchanges, different wallets, custodial solutions, token trackers, etc. These are unlikely to be useful to you unless you already believe cryptocurrencies have value. So that means the number of things you believe are useful built on top of it is small, and most early applications are hidden from you.
>The article implies that the infrastructure is like sitting there waiting for apps.
As for what the article implies, I didn't get that read. When I build apps, I also have needs that arise that I wish someone else built the infrastructure for. The common thing I run up against is that I wish I had a easy-to-setup data pipeline with resilience, reproducibility, and observeability. Apps inspire need for infrastructure, just as infrastructure inspires apps.
In an infrastructure sense, I view cryptocurrencies as a settlement network of transferable value.
The problem is that the electric grid doesn’t come from lightbulbs. They both come from people wanting to do stuff in the dark. Airplanes and airports come from people wanting to get places faster.
The whole concept of the article is still backwards, it’s still trying to rationalize why there have to be blockchain apps and infrastructure. There doesn’t.
There currently is no need for 'Web 3.0' as a phrase. The Internet of Things is a thing that could arguably be called 'Web 3.0' but that internet connected refrigerator is not needing the 'Web 3.0' moniker to convince people to buy it.
From a spade-a-spade point of view, blockchains are very slow,expensive and limited log database.
The main purpose of cryptocurrency is to replace the role of debt in our economy. The value of a cryptocurrency is determined by the economic value provided by entities which use that cryptocurrency as a medium of payment for goods and services. Because anyone can issue a cryptocurrency, the underlying tokens can behave like shares in a company.
Cryptocurrencies are better than shares in that they exist outside the laws of any single country. The ownership of tokens is not enforced by law, it is enforced by mathematics and your own ability to keep your passphrases secret.
Currencies have value only because governments force everyone to use them for paying taxes and welfare.
Your 'tokens-as-shares' vision is flawed, because at the end of the day it devolves into a million little barter schemes, and barter sucks. (As we discovered back in the bronze age.)
The only place where blockchain could provide a use is with smart contracts. If you've experienced buying or selling real estate, then you understand how insanely inefficient low-trust, high-value deals can be. Anything that removes this friction would be a great boon.
I used to think this but I don't anymore. Taxes are just one of multiple reasons why currencies have value. Some countries have no taxes and yet their currencies still have value.
>> Your 'tokens-as-shares' vision is flawed, because at the end of the day it devolves into a million little barter schemes
How is this different from the stock market? If you own shares of one company and you want to buy shares in a different company, you need to sell your existing shares for an intermediate currency first. It's a lot easier to do this using cryptocurrencies though (using Bitcoin as the intermediate).
Using tokens to pay for services is a proven concept; plane tickets, movie tickets, concert tickets, metal tokens for laundromats, food stamps, prepaid data quota for internet access... These are all tokens - the main difference is that they are issued by a central authority.
Cryptocurrencies open the door for universal services that have no central authority. They create an environment in which competitors can collaborate and mutually benefit through open source work.
I think you misunderstand how real estate contracts work.
Real estate contracts are more or less cut and paste, in fact you can generate them here: https://www.lawdepot.com/contracts/real-estate-purchase-agre...
The thing that takes the time is due diligence, finding and arranging money, and/or buyers. The actual contract is the easy part, unless you are putting in custom stuff.
Smart contracts are basically glorified escrow, but with no legal precedence. If something were to go wrong, and your smart contract doesn't complete properly, you'll still be going to court to carry out the remediation steps. Also, smart contract require mutual agreement to work properly, there is no over-riding system to mediate should things become undefined. (well, there could be, you need to program that in.)
The friction in high value deals is the due diligence. it doesn't matter if the contract is smart. Undoing a house move is expensive, having a contract where one party can terminate instantly without warning or redress is a dystopian nightmare.
if that were the case US Dollars would have no value in failed states.
There is nothing inherent in value, its down to consensus.
Git isn't write only, you can rebase. Its can't handle global consensus. You can read other peoples "world" and merge into yours, but it cannot aggregate the consensus and reject "illegitimate" change. You have two choices: "ours" or "theirs"
Write only? You can't read a blockchain? Does that mean bitcoin isn't a blockchain because of sites like www.blockchain.info ?
> & resistant to tampering, via global consensus.
Just don't allow pushes, only pull things. Voila, tamper resistance.
Just going home one day and saying, "I'm going to work on something" and then looking for something to work on never yields anything of use at the end of it.
A need has to burn before I can make appreciable progress on it. And once it's burning, it has my undivided attention until I can call my intervention complete and I can relax.
Companies can waste all kinds of money on building things that don't yet have burning needs. But if they want to be efficient with their spending, they need to treat that sort of thing with the same kid gloves as any other kind of research. As money you probably won't ever get back and won't lead to immediate revenue growth. As something you don't understand but hope to as a result of the process.
Because building 'infrastructure' is planning for a future that doesn't exist yet. Either solve a need, or go looking for one. The two should never be conflated because they require different mindsets.
I blogged about this a while back: http://tiny-giant-books.com/blog/process-scale-invariance-um...
I'm not a religious TDD person. I think it's the only way to professionally code mutable OO. At the business level it's the only way to manage your goals and progress. (ATDD, that is)
But the thing that TDD brought to the table that was missing from the larger discussion is that things exist in code (and infrastructure) for reasons. When you can create as much stuff as you like, it's important to make those reasons explicit. TDD is not a test discipline. It's a design discipline. You write the test first, then the code/infrastructure/business/whatnot is created to support the test. It's not just a fashionable thing to do. It's the only sane way to plan out architecture. Otherwise you're just kind of looking at thing ascetically.
And this is the reason we have such a framework explosion. You write function that does X, then you imagine X prime and X two, then you generalize, then you imagine some more. This is the same thing we see in startups: the desire to build over the desire to meet needs. Worst-case scenario is that people actually like 2 or 3 things out of your 100-thing toolset. Then you're off to the races building another 100.
Blockchain is still struggling with all of that. It's such an attractive tech they'll probably get it worst than most. It's quite seductive to see something you might need instead of something you actually need.
So if you see applications that already exist, then you don't want to build "just another application," you want to build the infrastructure they all live on.
It seems like this should be the way it works, but it just doesn't. Good products with infrastructure attract other enterprises to their infrastructure by having a very successful product first, which other enterprises emulate. Twilio is probably the #1 example of this.
I'd argue it's impossible to build infrastructure that others play on at scale, without owning some large segment of users with a great product first.
The Wright brothers didn't need airports to build the first airplane, but for commercial flight to exist airports must first be created. Likewise, I find many of the Web3 apps that I use to be perfectly fine as they are, because I know what I'm doing and I find the experience of being a trailblazer exhilarating hence why I also make my living building these platforms.
For most people, including plenty of highly competent technologists, it's still too far out and uncomfortable for them to use web3 apps, so we need to build better infrastructure that can accommodate other use cases, have better UX and dX, and bring in more people.
edit: Come and build the web3 with us! https://twitter.com/sserrano44/status/1048718205127151616