Hm… I’m not sure if this is enough to defeat the strategy.

It looks like even with that service, you have to sign up for Form 1583.

Even if they’re willing in incur the cost, there’s a real paper trail pointing back to a real person or organization. In other words, the bot operator can be identified.

As you note, this is yet another additional cost. So, you’d have say … $2-3 for the card + an address for the account. If you require every unique address to have no more than 1 account … that’s $13 per bot plus a paper trail to set everything up.

That certainly wouldn’t stop every bot out there … but the chances of a large scale bot farms operating seem like they would be significantly deterred, no?

Just pay $10 for every account that you want to create

So, making identities expensive helps. It’d probably filter out some. But, look at the bot in OP’s image. The bot’s operator clearly paid for a blue checkmark. That’s (checks) $8/mo, so the operator paid at least $8, and it clearly wasn’t enough to deter them. In fact, they chose the blue checkmark because the additional credibility was worth it; X doesn’t mandate that they get one.

And it also will deter humans. I don’t personally really care about the $10 because I like this environment, but creating that kind of up-front barrier is going to make a lot of people not try a system. And a lot of times financial transactions come with privacy issues, because a lot of governments get really twitchy about money-laundering via anonymous transactions.

EDIT: I think that maybe a better route is to try to give users a “credibility score”. So, that’s not a binary “in” or “out”. But other people can see some kind of automated assessment of how likely, for example, a person might be to be a bot.

thinks more

I mean, this is just spitballing, but could even be done not at a global level, but at a per-other-user level. Like, okay, suppose you have what amounts to a small neural network, right? So the instance computes a bunch of statistics about a each user, like account age, stuff like that, and then provides that to the client. But it doesn’t determine the importance of those metrics in whether the other user should see that post, just provides the raw data. You’ve got a bunch of inputs to a neural net, then. Then the other user can have a set of classifications. Maybe just “hide”, but also maybe something like “bot” or “political activism” or whatever. And it takes those input metrics from the instances, and trains that neural net to produce client-side classifications, and then auto-tags users based on that. That’s gonna be a pain to try to defeat, because the bot operator can’t even see how they’re being scored – they haven’t “gotten over the hurdle” or not.

But you don’t want to make every end user train a neural net from scratch. Hmm.

So maybe what you do is let users create their own scores and expose those to other users, right? I think that I read that BlueSky does something like that, was working on letting users create “curated feeds” for other users. They’re doing something simpler, no machine learning, but that’s got some drawbacks, means that you have to spend more time determining whether a score is good. So, okay. Say I’m gonna try to score a user based on whether-or-not I think that they’re a bot. I have the option to make that score publicly-available. Other users can “subscribe” to that metric, and when they do, there’s a new input node added to their local classifier’s list of input nodes. Like, “Dons Bot list”.

But I don’t have to subscribe to Don’s Bot List, and even if I do, it doesn’t mean that I automatically consider that other user a bot. Don’s rating is just an input into whether my own classifier considers them a bot. If I regularly disagree with Don, even if I’m subscribed to his list, my local neural net will slash the importance of his rating. If I agree with Don unless some other input to my classifier’s neural net is triggered, then the classifier can learn that.