We can look at PeerTube for an example of a system that could be shaped into what I meant:
when you look at a post (video) from peertube it links lists for likes, dislikes and shares (so basically upvotes, downvotes and boosts). These collections contain a totalItems property, but also list the peoples identities, but just imagine that it wouldn't be there.
When a user now likes the video, the creator of the video now sends out an Update acitivity to all subscribers. Now all subscribers can update the counts for likes, dislikes and shares. Only the "home instance" of the creator account knows about all votes, nobody else does, but nevertheless everybody else can now how many likes, dislikes and shares there are.
If we compare that to mastodon the first part of the statement is still true:
Only the "home instance" of the creator account knows about all votes, nobody else does
But that means that most instances just show 0 likes for most of the posts, because your instance only knows about likes originating from your instance...
As for your proposition: I couldn't follow for some of it. However I think the risk of an actor abusing the creation of fake accounts and fake upvoters is not really a risk, that is what defederation is for... I would argue very much agains a lemmy specific protocol and some judge instances simply because then big instances would just have pretty much all the data again and it would definitely hurt interoperability because lemmy devs can then just take the easier route instead of implementing something according to AP spec
You cannot make votes completely private, one instance has to have the authority over which votes do exist. This instance should be the origin of a post or comment.
At the moment it works like this: you upvote a post, this upvote gets send to the author of said post AND the magazine and that magazine then broadcasts your upvote to all subscribers of said magazine.
I could imagine that the process looks a lot different: you upvote a post, this upvote gets send to the author of said post, the author of the post then sends an update to the magazine saying how many people have now upvoted their post and the magazine then broadcasts this info to every subscriber of the magazine.
With that you would of course have new limitations concerning moderation and maybe there are trust issues regarding the correct reporting of that upvote count, but only the author of the post (and their instance ofc) could technically know who upvoted their post. As in everything here this is a compromise and whether the gained privacy is worth the other limitations, I don't know
Upvotes were already implemented when we did the fork. I guess we just never really thought about it. I honestly just have no opinion on whether upvotes should be public or not, so I don't mind them being public, but I basically never check who upvoted my posts anyway, so might as well be removed... If people care about this I'd say it is just up for discussion...
I was actually the one removing it. I implemented the support for incoming downvotes and because I and others had concerns to keep showing remote users downvotes publicly we / I removed it.
On mbin users can only see who upvoted a post. An admin can of course still go into the db and look there, but for users and mods there is no way to see who downvoted a post
I can absolutely understand that. I was very surprised as well as I stated often 😅
I can only tell you that I've been running my mastodon server a little longer and I commit to the mastodon server covenant (I think that is what its called). But if you have any doubts you should join fedia.io. Jerry has been a reliable admin for years and years (of all kinds of services)
I used recharts
Though one rendered it with google charts and that did look a lot nicer, but if one fine tunes it, then it will probably look equally good
You have the "easy" buttons for users that just want to sign in and don't think about it and then you have the "choose your own" button underneath it. I still am not a fan of this design, but I really care for decentralization and they want to attract "normal" people as well
When my instance turned on registration applications, there was a 10x drop in the number of registrations, and I've heard similar numbers from others.
The question is how much of these registrations are spam accounts. I have open registrations on my mastodon instance and ~70% are spam accounts that I delete within the first day...
I used 2 different metrics to rank the communities:
at first I sorted the communities by their total subscriber counts. The two diagrams coming from this sort are easily recognizable because hexbear has a big chunk of the communities in them.
the second one ranks them by active users per month. These are the ones where lemmy.world has >50%
For each of the 2 ranking metrics there are 2 different chars:
Labeled "By Community Count": just count the amount of communities out of the 100 biggest that are on a given server
Labeled "By Community Users": sum up the amount of users (active/month or total suscribers) in all of the 100 biggest that are on a given server
We can look at PeerTube for an example of a system that could be shaped into what I meant: when you look at a post (video) from peertube it links lists for likes, dislikes and shares (so basically upvotes, downvotes and boosts). These collections contain a
totalItemsproperty, but also list the peoples identities, but just imagine that it wouldn't be there. When a user now likes the video, the creator of the video now sends out anUpdateacitivity to all subscribers. Now all subscribers can update the counts for likes, dislikes and shares. Only the "home instance" of the creator account knows about all votes, nobody else does, but nevertheless everybody else can now how many likes, dislikes and shares there are.If we compare that to mastodon the first part of the statement is still true:
But that means that most instances just show 0 likes for most of the posts, because your instance only knows about likes originating from your instance...
As for your proposition: I couldn't follow for some of it. However I think the risk of an actor abusing the creation of fake accounts and fake upvoters is not really a risk, that is what defederation is for... I would argue very much agains a lemmy specific protocol and some judge instances simply because then big instances would just have pretty much all the data again and it would definitely hurt interoperability because lemmy devs can then just take the easier route instead of implementing something according to AP spec