Instances, of course, have some bot-mitigation tools which they can use to prevent signups, etc.

However, what’s stopping bots from pretending to be their own brand new instance, and publishing their votes/spam to other instances?

Couldn’t I just spin up a python script to barrage this post, for example, with upvotes?

EDIT: Thanks to @Sibbo@sopuli.xyz ‘s answer, I am convinced that federation is NOT inherently susceptible, and effective mitigations can exist. Whether or not they’re implemented is a separate question, but I’m satisfied that it’s achievable. See my comment here: https://programming.dev/comment/313716

  • AlternateRoute@lemmy.caEnglish
    51·
    1 year ago

    The more threads I read about both the federation issues (bad instances with bad rules) and lack of default user sign up validation controls. I really wonder if NONE of the design team have ever used web forums (phpBB, SMF etc) or managed an email server (default no encryption / trust, with TLS, SPF, DMARC layered on after the fact). These systems have been strugglingly with spam and bot controls for years and ZERO protection was mandated in the spec for this new open system.

    Maybe something could be learned from how block chain systems (not specifically crypto) are build where there is federation but distributed cost and tracking of identity. IE identity is global not managed by an instance, and spamming has a cost. IIRC one of the new registration options ads some cost to the registration but it is still instance based.

    I can understand the desire to be open, decentralized, and antonymous. However we still need a way to identify bot69 across the board and block them if they are a bad actor, and instances should have some form of trust built in even if it is other instances flagging them as trusted and that increases their trust or something.