You can compare total better than per user at these scales.
Lemmy needs a certain amount of performance to keep up with federation, but once you have all the images and posts and comments you don’t need second versions until you scale to a size that mandates multiple machines. Which I would guess is more in the 6+ digit user range, where you start averaging requests per second not minute.

In some sense, every lemmy user is a user of your instance via federation. You need to pay the performance for all 100k of us whether your instance has 10 or 10k of those. Local users are just a bit extra demanding on your hosting resources.

I suspect the bias we see here with larger instances paying a bit more (50-ish instead of 10-ish) is more due to reliability and snappyness than actual performance needs too. You tend to get optional smaller-gains pricier perks you might not go for for a smaller instance.

Link is detected without the emoji in my app. You might wanna hardcode the link as https://en.wikipedia.org/wiki/😂
[https://en.wikipedia.org/wiki/😂](https://en.wikipedia.org/wiki/😂)

i2p doesn’t really have exit nodes, it’s mostly for i2p internal connections.
The only exit I know is stormycloud.i2p, and that one is somehow immensely limited ro the point of it being hard to load clear-net text pages.

This would solve some of the problems. If only 2 instances know about the votes, post instance and sublemmy instance, you can reasonably expect to get most instances to never release that info. It would allow either the sublemmy or post instance to manipulate around in the votes, but most manipulation would be detectable by the respective other instance.

It would open the door however to manipulating around with internal posts made from the instance in a sublemmy on the instance. And it would allow the post instance to drop votes selectively, though I think that is possible currently all the same.

Votes being sent to both the sublemmy and the post instance simultaneously would make manipulation a lot harder. And for cases like internal posts, you could add another involved “judge instance” that receives the vote details directly from source, and is merely there to confirm the total. Instances that hand out non-independent “judge instances” could be labeled as untrustworthy in the lemmy community.

So you end up with a list of instances per post that votes are reported to, to which you add the post instance, sublemmy instance, judge instance, and maybe some more.

In terms of implementation, I think the activitypub protocol needs an origin for votes, right? I would say an instance can just report the votes coming from a stock of obviously fake accounts, like “masked_upvote_1” to _999999 … and “masked_downvote_1” to _XYZ.
About the votes, I am not sure. It could be done as a lemmy-internal feature where lemmy instances and other instances knowing of the lemmy protocol send the info to all the relevant instances, while any votes from external instances only arrive at I guess the post instance and that then forwards it on to all other instances. This way the checking doesn’t work for software unaware of that lemmy specific vote implementation, but everything is still compatible.

You could then even for those lemmy-external votes add an interface on the judge instance, that would confirm via pm if your vote has arrived.

Do you think this could work?

In my case I would like them to be private, but currently they are not. I don’t think it is good to try to hinder the visibility into a fundamentally transparent system.

I don’t see a technical way to make votes private either, that doesn’t prevent bad actor instances abusing the vote system. As an admin of an instance I could just add 5-10 votes to all of my interactions whenever I feel like it, and noone would be able to tell it didn’t come from legitimate users on my instance. The accounts of vote origin are needed as proof, hence moderators on lemmy having access to them.

Do you perhaps have any idea how this could be accomplished?

That’s a pretty reasonable compromise, and probably explains my confusion.
Why didn’t you do the same for remote upvotes?

Then maybe it is still around on some instances?
Either way, it is only a matter of time for another fediverse software to show downvotes, or someone to spin up a vote info page which gets its information via undisclosed legitimate fediverse instances so you cannot defederate them.

There is a “Reduces” tab on mbin, which shows downvotes

Nice

Currently the main repo.
Ideally youd take the definitely broken ones into the archive.
But there is always someone still using them just fine, how could you possibly tell when an app isn’t useful anymore?

Archive is for old versions not old apps. As in if you don’t wanna fiddle with versions you have no reason to enable the repo.
It will only cause casual users issues with not finding apps

In light of the current drama, could you maybe elaborate on your run in, and repeat what the deleted reply by stamets was?

OpenSUSE 42.3 standing tall

mpv

What’s this? ECDSA for ants?

Heres my pubkey, please enter it into your /root/.ssh/authorized_keys

AAAAB3NzaC1yc2EAAAABJQAAAQEAhH6uQMqlxUq6sLClnPp03DFbe3ETyqk6hE4k65y8U8yoGY2PsUV8YOOXaQFsGm0bpAFvAbEZwlJBlUP2bx04joV4N70/5NKbeAp6wS5HAiPHdbtaF/5UpqSPC3lkWdcb6WcS+uexdFk/LXKl3kKKw5xD9L7X1M3M/q04NHadOnDvzgmTKnM3bhn7WmSsx3thGDebEN+5ERk/Z85xQI/li201h5ab6B+G2FOQ0MKHw5VqqMUCjimimkXz1tVaYFoZ0oByM8otHyt/+b/DGvx3FGU6O1qgpWdpm3lWrkT300fZCxKlprQag0WaSa7n2i6FBPbUtmbGnI+c/2BD7kDVJw==