Conversation

Notices

1.  (mint@ryona.agency)'s status on Sunday, 16-Apr-2023 21:54:35 JST 

   • Zero :zt_think: :artix:
   • pistolero :thispersondoesnotexist:
   • † top dog :pedomustdie:
   • ¢нαяℓιє яσσт
   • blockbot
   • welcome_bot
   @dcc @blockbot @charlie_root @welcomebot @p @zero The problem with that implementation I see is that it's still open for spam if the attacker times their blocks in a way that the next block is sent right after the initial cache entry has expired. It is rate-limited, sure, but you would still wake up to the gorillion notifications. Could probably be solved by increasing the amount of time the entry is stored, the suggested 5 seconds is just too little.
   •  (mint@ryona.agency)'s status on Sunday, 16-Apr-2023 23:56:48 JST 

     in reply to

     • Zero :zt_think: :artix:
     • pistolero :thispersondoesnotexist:
     • † top dog :pedomustdie:
     • ¢нαяℓιє яσσт
     • blockbot
     • welcome_bot
     @dcc @blockbot @charlie_root @p @welcomebot @zero Alright, here's what I came up with.
     https://git.kiwifarms.net/mint/pleroma/src/branch/ryona-dev/lib/pleroma/web/activity_pub/mrf/high_roller_policy.ex
     Three-in-one policy for block, unfollow and report notifications, using Cachex for rate limiting. If the same kind of activity is sent to the same recepient, or if the sender sends more activities than defined in threshold, then no notification is sent. Scopes, messages, tagging, grey/blacklists, all configurable for those bad actors than want it. Lots of duplicate code which can be tidied up, but I was more concerned about whether it would work than how it looks.
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Monday, 17-Apr-2023 02:13:27 JST pistolero :thispersondoesnotexist:

     in reply to

     • Zero :zt_think: :artix:
     • † top dog :pedomustdie:
     • ¢нαяℓιє яσσт
     • blockbot
     • welcome_bot
     @mint @dcc @blockbot @charlie_root @welcomebot @zero Yeah, that requires a lot more effort, though: the CSV upload doesn't wait five seconds, it sends the blocks out as quickly as Pleroma/Mastodon can fabricate block activities. That is accurate, though, it's still got problems; I tossed out some other ideas. Tweaking the threshold would be fine. If it's a DM, though, the extent of the problem is much more limited.
      likes this.
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Monday, 17-Apr-2023 02:13:42 JST pistolero :thispersondoesnotexist:

     in reply to

     • Zero :zt_think: :artix:
     • † top dog :pedomustdie:
     • ¢нαяℓιє яσσт
     • blockbot
     • welcome_bot
     @mint @blockbot @charlie_root @dcc @welcomebot @zero :bigbosssalute:
      likes this.
   •  (mint@ryona.agency)'s status on Monday, 17-Apr-2023 02:18:04 JST 

     in reply to

     • Zero :zt_think: :artix:
     • pistolero :thispersondoesnotexist:
     • † top dog :pedomustdie:
     • ¢нαяℓιє яσσт
     • blockbot
     • welcome_bot
     @p @blockbot @charlie_root @dcc @welcomebot @zero You heard him.
     Husky_1681665466149_BX73IB5OE7.…
   • pomstan (pomstan@xn--p1abe3d.xn--80asehdb)'s status on Monday, 17-Apr-2023 02:22:58 JST pomstan

     in reply to

     • Zero :zt_think: :artix:
     • pistolero :thispersondoesnotexist:
     • † top dog :pedomustdie:
     • ¢нαяℓιє яσσт
     • blockbot
     • welcome_bot

     @mint @blockbot @charlie_root @dcc @welcomebot @p @zero ooooohh grudge match

      likes this.