Offloaded identity verification

Instead of making people pay to get verified, also offer (maybe also only for paying users, I don't care) the ability to guarantee authenticity by allowing to associate a public signing key with the account (as hidden payload). Authors can (via client extension) sign their messages (client side), and users can then verify (either via client extensions, or via their social media network JS code) the authenticity of a message, and can even pull the public key for checking the signature from a "trusted" source (for the sake of discussion only, let's assume the website of the newspaper of the journalist publishing the message in question). See Farcaster¹, for example.

If this is based on an open protocol, this alone could solve part of the "multiple accounts"/federation mess. I.e. this would completely decouple identity management from message authenticity verification: users can always go to the authoritative (third party or first party) key provider and don't have to trust the first party (i.e. the social network operator). Assuming they have out of band information about who the authoritative key provider for the person in question is.

One thing that is not solvable any other way is the case of personnel of the social media network operator publishing fake messages: under this model, they never have the private signing key, so anything they publish under the author's name fails validation (assuming user's clients have pinned the fact that this author uses external third party key; otherwise the fraudster could just change the account info to first party signing).

The majority of content producers can just use the first party (the social network operator) for both publishing and and key provisioning (per default, without knowing about it at all).

Of course, this has all the problems of normal public key infrastructure and would require a minimum of effort and care on the user side, so this does not have any chance.