CoderKat

Barriers are relative. Everything that makes it slightly harder will stop a large chunk of bots, since bots aren’t able to easily adapt like humans can. Plenty of very basic bots are in fact stopped by lack of emails.

But yeah, email verification is heavily more so that you can verify they have access to the email, and thus the email is safe to use for things like password resetting. Without it, webmasters can get swamped with complaints about people getting locked out of accounts or the likes because they signed up with the wrong email.

In theory, you can also go further by only allowing email providers that have anti bot mechanisms, but it’s difficult to maintain that and it will always exclude some legitimate users.

I’m very skeptical that mCaptcha would actually work besides perhaps temporarily slowing bots down due to being niche. How expensive can you make it without hurting legitimate users? And how expensive does it need to be to discourage bots? Especially when purposefully designed bots can actually do the kinda math we’re talking about in optimized software and hardware while legitimate users can’t.

You can’t aggregate them internally, anyway. You need to be able to know if someone already voted on something.

I think activitypub needs to be extended so that the likes and reduces only need to be sent to the host of the content, with federation then being told just the aggregate number. Then the only servers that need to know identity of votes are the host server (necessary to ensure nobody can multi vote) and optionally the server the user voted on (could just relay the information to the host server and not store it locally, but then it’d be harder to tell what you’ve already upvoted – could use local storage but I think lots of people use social media on multiple devices).

Sometimes reporting technically covers the last one. But usually not. Not all subs have rules against bigotry, trolling, dog whistles, general assholery, etc. I strongly hold it’s important that downvoting is an option to deal with these kinda things. It’s a way to show everyone that the comment isn’t acceptable.

Plus even when reporting is an option, it may not be fast enough. Can’t really automate removals, either, as people will abuse that.

Arguably “disagree but acceptable” should just not upvote. In a certain sense, that’s already a middle option.

“has anyone from my server interacted or searched for the post by it’s URL” is misleading. I struggled with this yesterday. Turns out you have to search in a very specific way.

In both kbin and Lemmy, you can’t just go to the community’s URL (which is utterly bizarre). You must search the full magazine name. In Lemmy, you weirdly need the ! in front when searching it to find it. In kbin, you don’t need that, but you do need to search the magazine in the “neutral” search mode, not magazine search mode (lol wut?). Actually, in Lemmy you also have to use the “normal” search field and not the community search field.

And of course, both have a discovery issue. People want to be able to search a partial string like “hobby” without having to know what instance their community might be on or if the full name might be things like “hobby_discuss”, etc. They should not need a separate tool to do this search. That’s just a barrier to entry.

Anyway the whole thing is a usability barrier that needs to change. It also makes smaller instances actively harder to use, which is a bad incentive. We don’t want people to experience small instances as “buggy” (even if it’s working as intended).

Anyone currently trying to create a sub should have an account on every major instance and subscribe to their new sub to ensure it shows up in the search. And yes, that is just completely silly (and unscalable beyond the biggest instances).