Unfortunately there are only three ways to implement decentralised webapps. Either you have trustless consensus by giving users power proportional to their physical resources where every user only has a small fraction of power. This is called blockchain with proof of work. It's extremely inefficient and therefore many usecases are not possible but it doesn't require trusting in any individual, only in the entire network. It should used for DNS, usernames or other readable identifiers that require global consensus.

The second is federation like email. Everyone has the option to become a provider or trust an existing provider. Of course the problem is that you need to trust your provider and the providers have to trust other providers. Spammers can just set up their own provider to attack other providers, so providers need the ability to block providers they disagree with. Providers don't live forever or they can become untrustworthy, there needs to be a way to export the data and import it into a new provider. You will need digitally sign all your data to prove that it came from you. There also needs to be a mechanism to confirm that user10@oldprovider is the same user as user5@newprovider and redirect from the old identifier to the new one.

The third is the least likely. A full P2P architecture where every peer is equal. Every peer will be forced to store the entire database of the application and run all computation locally. Spam will be an even bigger problem than with federation because you will have to store the spam for eternity too. The dataset will eventually become large enough that a single computer cannot store it.

I'm betting on federation. It's the middle ground between full centralisation and full decentralisation.