Fediverse

8 readers

2 users here now

This magazine is dedicated to discussions on the federated social networking ecosystem, which includes decentralized and open-source social media platforms. Whether you are a user, developer, or simply interested in the concept of decentralized social media, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as the benefits and challenges of decentralized social media, new and existing federated platforms, and more. From the latest developments and trends to ethical considerations and the future of federated social media, this category covers a wide range of topics related to the Fediverse.

founded 2 years ago

How does the fediverse handle upvotes on different instances? Does each instance have its own count or are upvotes summed up across multiple instances if the upvotes system (upvotes/boosts/likes) is s (kbin.social)

submitted 1 year ago by [email protected] to c/[email protected]

14 comments fedilink hide all child comments

In the latter case, I think it might be feasible to prevent upvotes from being counted multiple times if the username is identical on different instances, since upvotes are public. Is there already a mechanism to do this?

Also, isn't it much more common in the Fediverse than on central platforms for the same user to have multiple accounts with different usernames? This seems likely to me, if only because popular usernames may already be taken on a given instance. In this case it seems to me hardly possible to prevent double counting. I suppose this would only be possible if the different instances would log IP addresses and share this information with other instances. That doesn't seem desirable to me at all, and probably wouldn't be legal, at least in Europe, because of the GDPR. Are there other possibilities? Cookies?

Please excuse the maybe stupid questions - I'm new here and not very good at finding info on my own yet...

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 1 year ago

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.