I worked on Bitcoin in the early days, and developed decentralized software and protocols as part of that. I also did most of the design on an "enterprise blockchain" system later which is basically (in my view) a peer to peer database run by competing 'frenemy' businesses, i.e. with mostly untrusted nodes. So I feel like I have a lot of practical experience in this domain.

The RFC is decent enough. It's moderate and reasonable, and cites Marlinspike's "ecosystem is moving" essay which is a very important piece of thinking in this space. I'm not a fan of the RFC's friendliness towards regulation. Governments often achieve the opposite of what they want when they try to regulate the internet, and they don't care about centralization at all or in fact prefer it because it makes it easier to engage in control when there are only a few big players vs thousands of smaller players (see how modern EU regulation is explicitly targeted only at "very large platforms" and ignores the rest).

But the RFC lacks specific suggestions. For engineers who want concrete and achievable ideas that can be worked on with minimal cost, here are a few I'd pick:

1. Support IPv6. Getting flat end-to-end routing working again is one of the lowest lift ways to improve decentralization on the modern internet, in both obvious ways (reducing CGNAT) and less obvious ways, for example it's conceivable that Android could be extended to support socket activation. That would allow apps to bypass push notification and centralized reflectors in some cases. I'm not sure how commercially strategic push services are to Apple and Google these days - it costs a lot of money and it was revealed recently that governments are wiretapping supposedly e2e encrypted messengers by grabbing the push messages. So whilst I doubt Apple would allow it, in theory someone could write a patch for Android to enable it and contribute it upstream.

2. Support confidential computing. A lot of centralization happens because we need a program to be run on a server somewhere to do something sensitive, which means we need to trust the server operators (cloud+admins). So we gravitate towards big brands that everyone can agree on, like AWS. Confidential computing lets client apps (phones, desktop apps, less easily also web apps) to verify the server they're connecting to is untampered with and running the expected software. It takes cloud and root out of the trust equation, meaning you can in theory do things like have a P2P network of anonymous operators who offer their services without needing horrifically complicated and ad-hoc app specific cryptography. The tech works today, but very few people are aware of it or use it, and it's not integrated well into our tech stacks. But it should be!

3. Write smartphone, tablet and desktop apps. Web apps are inherently very centralized. The name of the app is conflated with its hosting location, browsers practically force you to delegate most of the app's work to the server, and user data ends up tightly bound with the operator and implementation. You can't even do tricks like confidential compute with them really, because browsers don't understand the remote attestation protocols. If you write client-side apps you can dodge all those problems and loosen the bindings between user data location, software distribution location and compute location.

Still, you have to be realistic. After some years I realized that centralization happens because decentralization is in some sense like communism. If you take away ownership over private property then people lose the incentive to improve it. It becomes a commons and the usual tragedy follows. Centralized services are private property, and so the owners make sure they are well kept and improved. Also private property and profit is mentally grounding - projects that lack these things have a habit of going crazy and losing interest in what users actually want. These days I'm not quite so interested in pure open source p2p systems anymore because of that problem, but there's a lot of scope to find interesting corners where private property can be combined with more decentralized implementations. After all, Office 2000 was owned by Microsoft yet still much more decentralized in practice than Office 365.