this post was submitted on 09 Jul 2023
1923 points (97.1% liked)

Fediverse

17698 readers
2 users here now

A community dedicated to fediverse news and discussion.

Fediverse is a portmanteau of "federation" and "universe".

Getting started on Fediverse;

founded 5 years ago
MODERATORS
[email protected]
[email protected]
1923
PSA: Lemmy votes can be manipulated (feddit.nl)
submitted 1 year ago by [email protected] to c/[email protected]
360 comments fedilink hide all child comments
 

The best part of the fediverse is that anyone can run their own server. The downside of this is that anyone can easily create hordes of fake accounts, as I will now demonstrate.

Fighting fake accounts is hard and most implementations do not currently have an effective way of filtering out fake accounts. I'm sure that the developers will step in if this becomes a bigger problem. Until then, remember that votes are just a number.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 19 points 1 year ago (1 children)

Fake/bot accounts have always existed. How many times has a "YouTuber" ran a "giveaway" in their comments section?

[–] [email protected] 12 points 1 year ago (1 children)

Yes but you presumably had to go through a captcha to make each one, whereas here someone can spin up an instance and 'create' 1 million accounts immediately.

[–] [email protected] 2 points 1 year ago

This gives me an idea;

Don't store incoming data from remote instances into the "Main DB" immediately. Store them into SUBORDINATE DATABASES!

The logic of how you arrange these subordinate databases should be simple; depending on which instance you're communicating with you could select a subordinate database like so;

  • First; we need to have a "Main Delay" database. This database is used by all the instances we Both Federate With, and Mark as one we Trust! and we merge all records here into the main database on a specified timeframe to give ourselves a little time to roll back the clock if something betrays that trusted status.
  • Secondly we need to have unique little databases for each little instance that we Federate with, but do not yet mark with trust! These little DBs are merged into "Main Delay", then Main on a different time-delay schedule. This gives us even more time to roll back large-scale attacks, spam or flooding via ActivityPub as well as time to just smack the "Defederate" button as soon as they start to misbehave and, optionally, jettison the garbage data that caused the need for Defederation as well.