When an application says it is decentralized, I want to know which request we are talking about. The transaction may be validated by a distributed network while the screen in front of the user depends on a handful of conventional services.
Moxie Marlinspike's first impressions of web3 makes that distinction concrete. His experiments examine the intermediaries between ordinary clients and blockchain data, as well as the relationship between NFT content and the interfaces that display it. The essay is valuable because it follows working systems rather than treating decentralization as a property that automatically spreads to every component.
A typical user does not begin by running infrastructure. They install an application or open a page. That application needs a fast way to answer questions: what is my balance, what happened to this transaction, and which objects should appear in this list? An API provider can make those answers convenient.
Convenience has consequences. The provider can become a point of failure, a source of incomplete information or a place where usage becomes observable. The underlying ledger might remain available while the application becomes unusable. Those statements are compatible because they concern different parts of the system.
Follow one action
Suppose someone opens a wallet and inspects an NFT. The wallet asks for chain state, finds a metadata reference, fetches a description, retrieves an image and displays it. A marketplace may supply an indexed view instead of the wallet constructing everything directly.
Now remove one service. If the indexer disappears, can the wallet reconstruct the list? If the metadata server changes its response, what does the wallet accept? If the image is content-addressed, who is actually keeping a retrievable copy? These questions turn a broad architectural claim into something testable.
Running a node can change part of the answer, but it is a responsibility as well as an option. Software must be updated, storage managed and connectivity maintained. Many users will reasonably prefer a service that performs this work. A design that relies on everyone choosing the more demanding path needs to account for that preference.
I don't think the existence of intermediaries makes every distributed component pointless. It does mean that the benefits should be stated precisely. A user might gain the ability to move an asset to a different interface even if they normally use a centralized one. That portability is meaningful when the alternative can actually recover the necessary information.
The reverse is also possible: an application can advertise portable ownership while important behavior remains locked in a proprietary database. The token moves, but the useful experience does not. Evaluating that requires understanding the product, not merely identifying the chain it uses.
The most useful diagram would put control beside every dependency. Who can change the data? Who can refuse a request? What can the user verify locally? What survives if the original company closes?
I like these questions because they apply to ordinary software too. Every system has boundaries of trust and maintenance. Web3 becomes easier to discuss when those boundaries are visible, and when a claim about the ledger is kept separate from a claim about the service built around it.