This community was essentially unmoderated for a while and I've been recently approached to take over moderation duties here. What I don't intend to do is to change any existing rules here but to enforce what has piled up in the moderation queue.

The discussion under the recent post about spam accounts turned into a flamewar regarding US domestic politics which has literally nothing to do with the Fediverse.

With dozens of comments, I don't have the bandwidth to sift through them individually and I've locked the thread. The PSA about spam accounts still stands which is why I didn't remove the post. The accounts involved with that flamewar get a pass for this time. Consider this a warning. Further trolling about US political parties will result in bans.

I'm planing hosting an instance, and I think that in the end I'll have to let the users pay for subscription. But just when I was imagining how I should design the subscription, I found there's a dilemma arose from the nature of fediverse:

(assume that people really like my instance for some reason)

1. If I charge my users, they may simply register on another instance and keep interacting with my instance to avoid paying the fees.
2. I can limit activities of the users who don't register on my instance to force them to subscribe my instance, but such action is obviously destructive to the fediverse.

I think this is not only my own problem. I think every instances with some scale faces the issue of costs, and relying on donation forever may not be a long term solution. So here's the question: how to let the owners of the instances get paid without violating the values of fediverse, i.e. decentralization and federation? Moreover, the solution should let the instances with higher popularity earn more money, so that'll encourage people to host high-quality instances. And I just figured out a (possibly very rough) solution by integrating blockchain to fediverse.

First, there will be a blockchain. There will be these cryptocurrencies:

1. the universal currency, let's say "fedicoin". Fedicoin can be traded on trading platforms like normal cryptocurrencies.
2. the currency of every single instance, e.g. InstanceA coin for InstanceA, InstanceB coin for InstanceB. The instance-specific coins are only used for federation between instances.

and the blockchain holds these data:

1. how many fedicoins and instance-specific coins each instances owns.
2. how many fedicoins each non-instance users owns, if any. I guess it would be better that only the instances can own instance-specific coins.

For operating the blockchain, there should be nodes to hold the data and process the transactions. The nodes can be either served by the instances or the non-instance machines. The nodes earn fedicoins.

When instances are federating with each other, every "demand" requires paying some instance-specific coins. The price of each type of demand will be predefined in the federation APIs. For example, if a user on InstanceB want to post on InstanceA, then InstanceB have to pay 10 lemmy.world coin to lemmy.world, and vise versa.

To earn instance-specific coins to pay for the demands, all the instances will "trade" automatically with other instances, and the "exchange rate" will be determined by some algorithm, possibly based on the amount of demands between each two instances. For example, if on average the demand from InstanceB to lemmy.world is 5 times more than the demand from lemmy.world to InstanceB, than in a trade, InstanceB may get 1000 lemmy.world coin, while lemmy.world may get 5000 InstanceB coin.

There will be an upper limit for every instance to own other instances' coins. For example, when lemmy.world owns 100,500 InstanceB coins, which exceeds the limit 100,000, then lemmy.world will refuse to trade with InstanceB by InstanceB coins. Under such condition, InstanceB have to trade with lemmy.world by the fedicoin. The owners of InstanceB will have to purchase fedicoin to let InstanceB trade with lemmy.world to maintain the fedaration.

Currently I think that the exchange rate between fedicoin and an instance-specific coin should be controlled by the owners of each instance, because each instance may have different costs for machines and moderation.

Finally, (hopefully) we'll have a fediverse like this:

1. The highly-demanded instances earn fedicoins, which can be exchanged to real-world currencies. Such mechanism also encourages hosting high-quality instances and more open federation.
2. The instances can simply charging their users normally by real-world currencies, so the users don't have to bother about cryptocurrencies.

Other side notes: Defining the prices of the demands may be tricky? For example, if my understanding is correct, there's no actual action like "read" when instances are communicating with APIs.

For the automatic trades between instances, of course there should be some controllable configuration, e.g. "don't buy coins over some price from some instances".

I'm just interested in the fediverse, and I hope my ideas can be helpful for its development. Any comments or crossposting are welcome and thank you for your reading.

Over the past 5-6 months, I've been noticing a lot of new accounts spinning up that look like this format:

• https://instance.xyz/u/gmbpjtmt
• https://instance.xyz/u/tjrwwiif
• https://instance.xyz/u/xzowaikv

What are they doing?

They're boosting and/or downvoting mostly, if not exclusively, US news and politics posts/comments to fit their agenda.

Edit: Could also be manipulating other regional news/politics, but my instance is regional and doesn't subscribe to those which limits my visibility into the overall manipulation patterns.

What do these have in common?

1. Most are on instances that have signups without applications (I'm guessing the few that are on instances with applications may be from before those were enabled since those are several months old, but just a guess; they could have easily just applied and been approved.)
2. Most are random 8-character usernames (occasionally 7 or 9 characters)
3. Most have a common set of users they're upvoting and/or downvoting consistently
4. No posts/comments
5. No avatar or bio (that's pretty common in general, but combine it with the other common attributes)
6. Update: Have had several anonymous reports (thanks!) that these users are registering with an @sharklasers.com email address which is a throwaway email service.

What can you, as an instance admin, do?

Keep an eye on new registrations to your instance. If you see any that fit this pattern, pick a few (and a few off this list) and see if they're voting along the same lines. You can also look in the login_token table to see if there is IP address overlap with other users on your instance and/or any other of these kinds of accounts.

You can also check the local_user table to see if the email addresses are from the same provider (not a guaranteed way to match them, but it can be a clue) or if they're they same email address using plus-addressing (e.g. user+whatever@email.xyz, user+whatever2@emai.xyz, etc).

Why are they doing this?

Your guess is as good as mine, but US elections are in a few months, and I highly suspect some kind of interference campaign based on the volume of these that are being spun up and the content that's being manipulated. That, or someone, possibly even a ghost or an alien life form, really wants the impression of public opinion being on their side. Just because I don't know exactly why doesn't mean that something fishy isn't happening that other admins should be aware of.

Who are the known culprits?

These are ones fitting that pattern which have been identified. There are certainly more, but these have been positively identified. Some were omitted since they were more garden-variety "to win an argument" style manipulation.

These all seem to be part of a campaign. This list is by no means comprehensive, and if there are any false positives, I do apologize. I've tried to separate out the "garden variety" type from the ones suspected of being part of a campaign, but may have missed some.

[New: 9/18/2024]: https://thelemmy.club/u/fxgwxqdr
[New: 9/18/2024]: https://discuss.online/u/nyubznrw
[New: 9/18/2024]: https://thelemmy.club/u/ththygij
[New: 9/18/2024]: https://ttrpg.network/u/umwagkpn
[New: 9/18/2024]: https://lemdro.id/u/dybyzgnn
[New: 9/18/2024]: https://lemmy.cafe/u/evtmowdq
https://leminal.space/u/mpiaaqzq
https://lemy.lol/u/ihuklfle
https://lemy.lol/u/iltxlmlr
https://lemy.lol/u/szxabejt
https://lemy.lol/u/woyjtear
https://lemy.lol/u/jikuwwrq
https://lemy.lol/u/matkalla
https://lemmy.ca/u/vlnligvx
https://ttrpg.network/u/kmjsxpie
https://lemmings.world/u/ueosqnhy
https://lemmings.world/u/mx_myxlplyx
https://startrek.website/u/girlbpzj
https://startrek.website/u/iorxkrdu
https://lemy.lol/u/tjrwwiif
https://lemy.lol/u/gmbpjtmt
https://thelemmy.club/u/avlnfqko
https://lemmy.today/u/blmpaxlm
https://lemy.lol/u/xhivhquf
https://sh.itjust.works/u/ntiytakd
https://jlai.lu/u/rpxhldtm
https://sh.itjust.works/u/ynvzpcbn
https://lazysoci.al/u/sksgvypn
https://lemy.lol/u/xzowaikv
https://lemy.lol/u/yecwilqu
https://lemy.lol/u/hwbjkxly
https://lemy.lol/u/kafbmgsy
https://discuss.online/u/tcjqmgzd
https://thelemmy.club/u/vcnzovqk
https://lemy.lol/u/gqvnyvvz
https://lazysoci.al/u/shcimfi
https://lemy.lol/u/u0hc7r
https://startrek.website/u/uoisqaru
https://jlai.lu/u/dtxiuwdx
https://discuss.online/u/oxwquohe
https://thelemmy.club/u/iicnhcqx
https://lemmings.world/u/uzinumke
https://startrek.website/u/evuorban
https://thelemmy.club/u/dswaxohe
https://lemdro.id/u/efkntptt
https://lemy.lol/u/ozgaolvw
https://lemy.lol/u/knylgpdv
https://discuss.online/u/omnajmxc
https://lemmy.cafe/u/iankglbrdurvstw
https://lemmy.ca/u/awuochoj
https://leminal.space/u/tjrwwiif
https://lemy.lol/u/basjcgsz
https://lemy.lol/u/smkkzswd
https://lazysoci.al/u/qokpsqnw
https://lemy.lol/u/ncvahblj
https://ttrpg.network/u/hputoioz
https://lazysoci.al/u/lghikcpj
https://lemmy.ca/u/xnjaqbzs
https://lemy.lol/u/yonkz

Edit: If you see anyone from your instance on here, please please please verify before taking any action. I'm only able to cross-check these against the content my instance is aware of.