this post was submitted on 05 Jul 2023
10 points (100.0% liked)

Fediverse

83 readers
3 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
10
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 2 years ago by [email protected] to c/[email protected]
15 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...

top 15 comments
sorted by: hot top controversial new old
[–] [email protected] 9 points 2 years ago* (last edited 2 years ago) (2 children)

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?

If @[email protected] upvotes and @[email protected] downvotes, how do we decide which is the canonical vote? How can we say for sure they're even run by the same user?

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 was the norm on Reddit too.

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?

Let's not inundate the fediverse with tracking cookies and privacy invasion.

I get where you're coming from, but I just think that the solutions to these problems aren't actually solutions, and they're a case where the cure is worse than the ailment.

[–] [email protected] 1 points 2 years ago (1 children)

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.

[–] [email protected] 2 points 2 years ago (1 children)

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.

I don't think this is realistic at all. It breaks the current philosophy of the fediverse where each instance can be both autonomous and federated. What would happen if for example an instance wanted to federate after they already had a couple accounts. Would they need to delete these users because the username exists? This is the reason that the second part (after the "@") exists.

Also look at the email. Ofcourse it is possible to have the same name with users in other email services. It would be very weird not to be allowed to get the [email protected] because the [email protected] already exists.

What you are suggesting introduces and requires a central authority that would be responsible for that, but this again, breaks the philosophy of the fediverse itself.

[–] [email protected] 1 points 2 years ago (1 children)

It'd not just break the philosophy, but the practical use of the fediverse. People use Mastodon, Peertube, and Lemmy privately amongst a friend group, or even on a LAN; maybe a small company uses Lemmy internally. Then they make it federated later, when they want more users, more content, whatever.

[–] [email protected] 1 points 2 years 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.

[–] [email protected] 1 points 2 years ago (2 children)

Simple solution, let us see who upvotes a post. Kind of like how Facebook lets you see you liked your post. It wouldn’t prevent posts from getting brigaded with bot votes, but it would let us see that it is happening. Oh 1k votes on this post? But half of them are from [email protected]? Probably bot manipulation.

[–] [email protected] 3 points 2 years ago

If you're on kbin, click on more and then activity. You'll see who boosted, who liked and who down voted said post or comment

[–] [email protected] 1 points 2 years ago

On the user profile you can see which posts a user has upvoted. But if you could see it directly on a particular post, it would be pretty helpful, I guess.

[–] [email protected] 2 points 2 years ago (1 children)

The answer is "badly".

It's even worse if you compare the way kbin vs lemmy handle upvotes.

Don't get me started on down votes.

But its good enough to mostly work on average :D

[–] [email protected] 1 points 2 years ago

Agreed, it's all a bit wonky, and it still mostly works. Really I think it's mostly down to a design problem in word-choice. "Boost" kinda makes sense in microblogging, but not in link-sharing (unless you know that your kbin also has a microblogging feature, which...) I think "repost" make a lot more sense but I think that horse is out of the barn, unfortunately.

[–] [email protected] 1 points 2 years ago (1 children)

Honestly, I'd be happy in a world without visible "Like" and "Dislike" counts. People with differing opinions always end up being punished by the current systems, encouraging group-think.

[–] [email protected] 1 points 2 years ago (1 children)

Like what opinions?

[–] [email protected] 1 points 2 years ago

Depending on the board, for example, if I said I like using an Apple computer, I would get downvoted to oblivion by zealots. I mean, just because people don't like my preference doesn't mean what I said is invalid. Also, I use Mac, Windows & Linux depending on the task. Fanboys can't understand that.

[–] jjagaimo 1 points 2 years ago* (last edited 2 years ago)

If I have it correct, each upvote is individually federated with the username and instance. Each instance will only consider upvotes (and downvotes only if they're enabled) from federated instances (and from non banned users?). So instances can see wildly different vote counts if you are on say lemmy.world or kbin.social. You could theoretically have multiple accounts with the same name but what is stopping two different people from having the same name at different instances?

A potential solution I've considered is a signing certificate which identifies a user which can only be granted to a human. Verifying that the person who received it was human would be difficult as you would either need to verify IDs, which is problematic in a number of ways:

  • anonymity
  • security risk if there's a breach
  • relies on trusting the certificate authority
  • IDs of less well known countries can be harder to verify or easier to fake

Or if identifying a unique person isnt necessarily needed, you could just accept going for a less strict standard and just try to verify the person generating the certificate is at least human and not a bot pumping out requests. One way is captchas, but thats can be relatively easy to pump through either an OCR bot or through a paid captcha service (they run human farms of people answering captchas)

That certificate would then have a slightly higher standard to receive and its private key can then be used to sign votes. This wouldn't prevent a single user from generating several accounts, but would help limit how fast and how many they could.

Of course, one could just add more layers of captchas and human verification directly to their lemmy or kbin sign ups, but the benefit of the certificate is that if you wanted to, you could link accounts (e.g. with same or different username) with the same certificate. This is less important in the fediverse and might in fact cause more problems such as people being blocked from instance A when it defederates from instance B even though they have an account on both. However it also means that if instance A permanently shuts down or loses all its data somehow, you still have access to your comments, upvotes, and posts as you can verify that you are who you say you are.

Another benefit is it shifts the sign up verification part from the instance itself, so it could be easier either for an instance to run signups on a different server or if its run as a certificate authority it could mean that instances dont need to sort through sign ups at all as long as the person has a certificate from a valid authority (though this relies on using trusted authorities only)

I'm not sure how easy the shift from non-signed to signed content would be; it would probably break federation with instances that haven't caught up, but then again the 0.18.1 update breaks it with 0.18.0 and it's not a huge deal at the moment.

ETA: another benefit is for better GDPR compliance, you can delete content and verify your account's identity without your instance running. Obviously the fediverse is a GDPR nightmare but its still better than nothing.

[–] [email protected] 1 points 2 years ago

I'm not sure it's possible to reasonably prevent, reddit had issues throughout its life because of it. I think they implemented measures but they were regularly bypassed. with federation it's probably impossible. I'm not sure how much it matters for most threads but it might be an unfortunate fact of life