Good to know, thank you!

Personally I think we should add a differentiation between the storage policies of content which is owned by your own instance and content that federates from other instances.

The former should be kept for a long time (forever?), while the latter can be cleared more regularly.

Yeah, a few times. It was especially helpful in finding causes of subtle UI bugs, to identify the exact commit which changed the UI.

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.

If “botters” are willing to spend >$5 per bot on established instances, then I don’t believe this is a solveable problem. For the fediverse, or for ANY platform, Reddit included. I am perfectly human, and would be hard-pressed to decline a >$150/hour “job” to create accounts on someone’s behalf.

Like any other online community, constant vigilant moderation is the only way to resolve this. I don’t see how Lemmy is in any worse position than Reddit so I don’t think we need to be all “doom and gloom” quite yet.

As for botters creating their own instances…

For example, newly created domains might be blacklisted by default.

This is just a start. Federation allows for many techniques to solve this. Perhaps even a “Fediverse Universal Whitelist” with an application process. I’m excited for the possibilities, but again I don’t think it’s quite time to be overly concerned yet. These are solvable problems.

There are two worries here:

1. Bots on established and valid instances (Should be handled by mods and instance admins, just like conventional non-federated forums. Perhaps more tooling is required for this— do you have any suggestions? However, I think it’s a little premature to say that federation is inherently more susceptible or that corrective action is desperately needed right now.).

2. Bots on bot-created instances. (Could be handled by adding some conditions before federating with instances, such as a unique domain requirement. Not sure what we have in this space yet. This will limit the ability to bulk-create instances. After that, individual bot-run instances can be defederated with if they become annoyances.)

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.

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. However I disagree with your assertion that the federation model is more risky than conventional Reddit-like models. Instance owners have just as many tools (more, in fact) as Reddit does to combat bots on their instance. Plus we have the nuke-from-orbit defederation option.

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.

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.

I appreciate your commitment to this privacy consideration. I personally don’t think it’s the hill I’d prefer to die on, but I welcome your contributions.

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.

As far as I know (another assumption haha), there’s no universal IDs across the fediverse.

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

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?

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.

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.

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

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.

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.

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?