You know I'm a committed user of the fediverse,  perhaps this post will surprise you. Still, at some point the truth has to be told, before lying leads to a catastrophe. I think I've been present in the fediverse (sometimes hosting a pod of some software and sometimes not) since
  • comfy@lemmy.ml
    2·
    3 years ago

    Thank you for the very detailed answer!

    Another was they almost didn’t include sharedInbox in the spec because Mastodon didn’t want to use it and thought it was stupid or evil or something. Luckily it still made it in but the compromise was that it was optional, putting extra burden on all other servers to support sending separate copies to every single user’s inbox.

    I’m not sure if it’s the same thing, but I recall a Gab developer justifying their removal of federation in 2019, one of the reasons being that malicious actors were spinning up fake instances with thousands of users to make a server send separate copies of a message to every single user’s inbox, slowing the site down. Would shared inboxes help to prevent this type of attack, or is it something else?

    • electrodynamica@mander.xyz
      2·
      3 years ago

      malicious actors were spinning up fake instances with thousands of users to make a server send separate copies of a message to every single user’s inbox, slowing the site down. Would shared inboxes help to prevent this type of attack, or is it something else?

      Indeed. Making sharedinbox a requirement would mean that a server could simply refuse to do it the other way and then be immune from that attack. But because it is optional, all servers must then be vulnerable to this attack.

      It can be mitigated by batching, and delivering say only 5 copies to one server at a time, but that would have to be very carefully crafted to not cause queue backup for other messages.

      The ultimate workaround is queueless delivery, but there will still always be some penalty of having to keep revisiting a particular server.

      A malicious actor can also deliberately slowly respond to deliveries, forcing the sending server to keep many sockets open.