Upvotes and downvotes could simply balance each other out. Since upvotes and downvotes are public, it should be possible to check the user profiles in question. But of course, besides surely being technically difficult, that would require that it’s actually the same person. This seems impossible to prove, as long as the same username can be registered multiple times on different instances.
However, I think it would be possible to keep a central database containing only the information which username has already been registered within the Fediverse - a bit like domain registrars. When a new user joins, the operators of an instance could look up whether the desired username is already occupied on another instance. This would certainly mean losing some autonomy, since the instances would no longer have sovereignty over available usernames. But I think it would be beneficial overall if usernames were only assigned once within the Fediverse.
For example, when it comes to counting upvotes and downvotes. But also to protect users from being discredited: I’m afraid that with the status quo it is quite easy to impersonate another user, since you can register the same username on another instance and do whatever you please with it. But that’s a completely different question, which I fear will become more relevant the more popular the Fediverse becomes (unfortunately, not only users with good intentions will join).
But please don’t get me wrong: I find the decentralized open source culture of the Fediverse extremely desirable - it is, in a way, a return to the utopia of the early Internet. I am very happy to be here and to witness that exchange among people is indeed possible without the influence of major corporations like Meta or reddit and all their buisiness schemes.
I just think it’s important to have a reasonably meaningful “random Internet points” system, whether it’s called karma or something else. I think these points are (unfortunately) the central motivation for many users to post content, which is probably why they play an essential role in the mass appeal of any social media plattform.
Yes, you are right - it’s not realistic: On the one hand because it would be hard to come to a consensus on which instances should be changing all those usernames that are registered on other instances at a given point in time. On the other hand there would always be the need to change some usernames.
You probably could have some sort of a best practice to check said public database (btw I meant more of a phone book, not a db where passwords are stored) even for unfederated, local or private instances so that the operators of those instances could only register “free” usernames. But it is indeed not acceptable at all to oblige private instances to feed their usernames into a public database as well. Accordingly, it would not be possible to prevent usernames from being assigned multiple times and having to be changed later on when an instances whose usernames were not in the database decides to federate. This probably wouldn’t happen all too often, but it would certainly happen regularly. I hadn’t thought of that.