I think this post misses one of the points in the original essay, which is that federation is less important for user-level protocols because the network layer

I think this post misses one of the points in the original essay, which is that federation is less important for user-level protocols because the network layer beneath it is open. That tilts the slow-moving-federated-service vs. fast-moving-centralized-service tradeoff towards fast-moving-centralized-service, which is why we see the landscape we see today. His argument applies for any centralized top-layer services built on top of open substrates. Because the substrates are open, users can relatively easily switch between centralized services, which lowers the badness of centralization, which in turn makes centralization a more reasonable tradeoff to make. The question he didn't address, I think, is what happens in the case where you have centralized services emerging on top of another centralized service. In that case users might be able to switch their top-level service providers, but it would be much harder to switch the lower-level provider. But then again, that's exactly the lesson that everyone in the software industry learned with the dominance of Windows as a platform in the '90s and early '00s, and I think that's why you see so many companies building proprietary layers on top of open source components, and the current growth of cross-cloud compatibility libraries. The user-facing service providers want to make sure they can never be hurt by a centralized platform underneath them. And that's the dynamic that I hope will end up protecting users as well.