Agreed from a technical standpoint.

But the implications are still interesting. One might (big might) trust Reddit as an organization not to use this data for evil, but with federation, there’s nothing stopping an instance from simply releasing all users’ voting history to be public.

Of course, my instance didn’t even ask for an email to sign up, so my entire account is anonymous that way.

I wonder if there are technical ways to federate votes anonymously?

Honestly, I’m interested to see how the federation handles this problem. Thank you for all the attention you’re bringing to it.

My fear is that we might overcorrect by becoming too defederation-happy, which is a fear it seems that you share.

Since it seems like most of these bots are coming from established instances (rather than spoofing their own), I agree with you that the right approach seems to be for instance mods to maintain stricter signups (captcha, email verification, application, or other original methods). My hope is that federation will naturally lead to a “survival of the fittest” where more bot-ridden instances will copy the methods of the less bot-ridden instances.

I think an instance should only consider defederation if it’s already being plagued by bot interference from a particular instance. I don’t think defederation should be a pre-emptive action.

So, are we saying we want more people to create accounts on Meta's Threads?

That's what defederation would imply: people who want to interact with Meta's folks and be in touch with Meta's community would end up creating accounts there. We'd be handing users to Meta by doing that.

Clearly, Meta has tons of resources to invest. If they have half a braincell among them, they'll be able to create some value with those resources. Given that they're launching Threads with or without federation, we now have two options:

1. We let Meta enhance the value of all instances.
2. We lock out Meta, and all their value created remains their own.

What are we even talking about here? A ton of people put in a ton of effort and work to create a platform where the whole point is to have different organizations be able to inter-operate without any one instance gaining too much power. As soon as someone with actual resources wants to contribute, we shut them out? Folks, if a single organization could bring down the fediverse, then the "decentralize so that no one can gain too much power" model is proven wrong, and it was bound to fail anyway.

If we become an echo chamber where the only one who can be part of the "fediverse" are people without resources, then what's even the point? Who wants an email service that can't send emails to Gmail and Hotmail, but only YourFriendlyLocalInstance.com?

The way I see it, we should absolutely not defederate. I'd prefer to see Google or Twitter also join the fediverse, and have them competing amongst each other to make sure we have enough competition to keep any of them from wanting to defederate.

EDIT: Quoting this deep child-level comment, which explains my point of view better:

We care about the vision of a “fediverse”, where all instances’ users can talk to one another if they choose. If that’s what we care about, there’s no choice here: federate, or you’ve already broken the vision.

Look, no one is saying that programming.dev should promote Meta’s content on their home page. Let’s beef up our moderation/content filtering tools:

• Let users block all Meta communities and all Meta users if they choose.
• Let users set that none of their posts should federate to Meta.
• Let community mods block all posts from Meta users.
• Let community mods decide never to let Meta users see any of the posts on their community.
• Let the instance owners decide never to feature a Meta user’s post or a Meta community post on “all” or “local”. Make it so that the only way to find a Meta post/user is by actively searching for it or subscribing to their communities.

That’s all well and good.

But defederation is worse than that. What defederation really means is: “Even if programming.dev users want to see Meta content or post there, we won’t allow it. Go create an account there instead.” As soon as you do that, it’s not a fediverse anymore.

True! Also instances could each do their own brand of “vote manipulation mitigation” by counting or ignoring different sources of votes.

Other cool features come to mind, like having a separate vote count for voters from the local instance.

Not a stupid question at all!

Lemmy and Kbin are two different systems that talk to each other. Like how Gmail and Outlook are two different systems, but you can still send emails between them.

So you can make posts over there on Kbin and I can upvote them from over here on Lemmy.

Make sense?

Could be hashed and salted, with a random salt.

The trouble is, then, that it’s harder to disallow users from voting multiple times if the voting user isn’t on the post’s home instance.

I see. So each instance in the “fediverse”, whether Kbin or Lemmy or Mastodon could have their own rules on what to allow. Those that allow too much and get spammed are likely to lose standing in the community and be defederated by other instances.

Requiring a domain and having a mechanism to block domains seems like a good approach to start with.

Thank you! That cleared it up for me.

Thanks for calling this out! Fixed, I hope. Wasn’t intentional.

Good on you for actually checking and not blindly assuming like me! Hahaha glad to see my assumptions bore out this time.

But yeah, even if lemmy doesn’t aggregate it, it would be possible to set up a bot pretending to be an instance which collects and aggregates vote histories.

You’re welcome! Hope it’s useful :)

I toss my KeePass file (encrypted database) in Google Drive.

That way I have all the convenience of syncing through the cloud, but I also get the benefit of having my database access and database storage be managed by separate companies.

If Google has a breach and my data gets leaked, sucks, but the database is encrypted so I’m good. If KeePass encryption is broken, sucks, but attackers would also have to find a way to gain access to my Google Drive.

There is NOTHING stopping these bots from just creating new instances, and using those.

I read somewhere that mastodon prevents this by requiring a real domain to federate with. This would make it costly for bots to spin up their own instances in bulk. This solution could be expanded to require domains of a certain “status” to allow federation. For example, newly created domains might be blacklisted by default.

I think this issue is overblown. Instances of Lemmy might run modified code and choose to save things that the user intended to delete, of course, but the default setup of Lemmy seems reasonable to me in terms of how it treats deletion.

Currently it keeps deleted posts forever to allow users to un-delete if they choose, but deleting your account clears everything. And I believe there’s work in progress to discard deleted posts after 30 days. Details here: https://github.com/LemmyNet/lemmy/issues/2977

Yes, that’s a fair point. Just because you send a “I have deleted this message” signal out into the universe doesn’t mean that everyone will receive or obey it.

I assumed that was understood.

But that’s very different from instances intentionally and malevolently keeping data despite indicating to users that it was deleted, which is what I think folks’ privacy concerns are about.

EDIT: What I mean is that the federation model is inherently non-private in a certain sense (but in the same sense that someone could take a screenshot of your Reddit comment and your deleting your comment won’t delete their copy). But Lemmy is not egregiously misusing data.

Agreed! I think this is generalizable to say that CSR is when you need to show "loading indicators" which is kind of annoying because.... I had to send the loading indicator from server -> browser.... so it was loading just to load some more.

Yes, true, the current system does allow that. But the current system also doesn’t allow users to accidentally vote twice (and it remembers your vote)— this is the feature I think would be more challenging to implement if we were to hash & salt the user's ID.

Agree! Defederation is a nuclear option. The more we do it, the more we reduce the value of "the fediverse", and the more likely we are to kill this whole project.

I think defederation should only be a consideration if an instance is consistently, frequently becoming a problem for your instance over a large period of time. It's not a pre-emptive action.

Hmmmm so I see that you pinged me in this post, but I didn’t get a notification for it. Wonder how that works.

I’m glad you like it! Cheers!

Good to know, thank you!