> For example, whether it’s running on mobile or the web, a dApp like Autonomous Art or First Derivative needs to interact with the blockchain somehow – in orde

> For example, whether it’s running on mobile or the web, a dApp like Autonomous Art or First Derivative needs to interact with the blockchain somehow – in order to modify or render state (the collectively produced work of art, the edit history for it, the NFT derivatives, etc). That’s not really possible to do from the client, though, since the blockchain can’t live on your mobile device (or in your desktop browser realistically). So the only alternative is to interact with the blockchain via a node that’s running remotely on a server somewhere. > As it happens, companies have emerged that sell API access to an ethereum node they run as a service, along with providing analytics, enhanced APIs they’ve built on top of the default ethereum APIs, and access to historical transactions. > Almost all dApps use either Infura or Alchemy in order to interact with the blockchain. In fact, even when you connect a wallet like MetaMask to a dApp, and the dApp interacts with the blockchain via your wallet, MetaMask is just making calls to Infura! > Imagine if every time you interacted with a website in Chrome, your request first went to Google before being routed to the destination and back. That’s the situation with ethereum today. This is a very common complaint about anything that claims to be decentralized. It was also surprising to me years ago when I first read about Bitcoin and realized that it's not practical to maintain the whole blockchain on most clients. However, how do ISPs fit into this analogy with "web 1"? Since we're assuming that the original world wide web was worthy of being called "decentralized," doesn't this same criticism apply to ISPs? Even if you ran your own web server from your own facility, presumably the ISP was a third party that you had to (in some sense) trust.