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.

  • festus@lemmy.ca
    12·
    1 year ago

    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.

    • Melody Fwygon@lemmy.one
      2·
      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.