2 ms·

> User A can have his client filter them out locally We've been trying that with email and spam for the last 3 decades and I've got to tell you the results are

> User A can have his client filter them out locally We've been trying that with email and spam for the last 3 decades and I've got to tell you the results are not good. > prior to when they'd otherwise be displayed. A has to download the harassment from B just to then filter it locally? Seems like you're putting the onus on A here to do the work. What happens if B sends enough to DOS A's link? Or sends CSAM and now A is committing a crime just by downloading the content? > as User B could log out, or use another account that hasn't been blocked Which increases the friction on B if they want to harass A - this is good! We want to make harassment as friction-full as possible!

Gigachad 4y ago
It works pretty well on email. When I mark a user as spam or set up a filter rule, all of their content goes direct to spam or even deleted if I want. Doesn't bother me at all. Email has also dealt with the spam issue mostly. If you blast me with too many emails, you get put on a spammer blacklist and servers will just drop the content without delivering it. It also isn't a crime to be unwillingly sent illegal content which you immediately delete.
- mort96 4y ago
  Email has not solved the spam issue. I regularly get obvious spam email in my inbox, and legit mail still goes in the junk folder from time to time – with gmail. Plus, the automated spam filtering systems make it practically impossible to host your own e-mail, and any self-hosted email will have even worse issues with inbound spam than gmail does. Spam is at the core of what makes email a terrible example of a federated system, along with absolutely terrible client compatibility issues.
  - Gigachad 4y ago
    That's irrelevant, automated blocking is a different discussion. This is about if it matters that the content hit your server or client and then was deleted because you had the user blocked, or if it's better to have a centralized system where the blocked users messages never make it to your client. From the users perspective I can't really see any difference here.
    - mort96 4y ago
      And from a users's perspective, spam makes it through and legit messages end up in spam and the whole email system is more or less centralised due to attempts at combatting the issue. Those are all user facing issues. Your ideas for client-side blocking in a federated system may be okay, I don't know. I'm objecting to the "Email has dealt with the spam issue mostly" thing; it absolutely has not.
      - ndriscoll 4y ago
        > the whole email system is more or less centralised due to attempts at combatting the issue Do the big email providers even attempt to combat spam? I got an email from booking.com yesterday that literally contains the text "This message is an advertisement." From what I can tell, Gmail hasn't maintained their spam filters in at least a decade.
- zimpenfish 4y ago
  > It works pretty well on email. As someone who has been running mail servers for 20 years, no, it does not. I'm sure other mail admins will agree.
  - account42 4y ago
    > I'm sure other mail admins will agree. Don't be.
    - zimpenfish 3y ago
      Then I, and no doubt many others, would love the disagreers to document their setups which have defeated spam because it is still a daily problem round these parts.
debugnik 4y ago
> We've been trying that with email and spam Aren't we talking about blocking and muting known user handles? This is easy, the spam problem would be identifying which handles to block. > What happens if B sends enough to DOS A's link? Or sends CSAM and now A is committing a crime just by downloading the content? What happens if B does the same before A had a chance to block them? And why would A's client download the content after reading that B published it from the metadata? > Which increases the friction on B if they want to harass A True, but I'm afraid we already know from Twitter that B will do it anyway, aided by either fast user switching or a Tweetdeck-like interface.
- zimpenfish 4y ago
  > Aren't we talking about blocking and muting known user handles? This is the same as blocking known spam domains and IP blocks in email. They just switch to a new one. Which is best dealt with at the remote end since the server has a better chance of being able to identify new accounts which are related to blocked ones - Instagram even suggests this for you when you block someone: "...and any future accounts they may create". Having to do this in A's client is much more difficult because it lacks the information that would be useful. > What happens if B does the same before A had a chance to block them? A fair point.

Gigachad 4y ago

It works pretty well on email. When I mark a user as spam or set up a filter rule, all of their content goes direct to spam or even deleted if I want. Doesn't bother me at all. Email has also dealt with the spam issue mostly. If you blast me with too many emails, you get put on a spammer blacklist and servers will just drop the content without delivering it. It also isn't a crime to be unwillingly sent illegal content which you immediately delete.

mort96 4y ago
Email has not solved the spam issue. I regularly get obvious spam email in my inbox, and legit mail still goes in the junk folder from time to time – with gmail. Plus, the automated spam filtering systems make it practically impossible to host your own e-mail, and any self-hosted email will have even worse issues with inbound spam than gmail does. Spam is at the core of what makes email a terrible example of a federated system, along with absolutely terrible client compatibility issues.
- Gigachad 4y ago
  That's irrelevant, automated blocking is a different discussion. This is about if it matters that the content hit your server or client and then was deleted because you had the user blocked, or if it's better to have a centralized system where the blocked users messages never make it to your client. From the users perspective I can't really see any difference here.
  - mort96 4y ago
    And from a users's perspective, spam makes it through and legit messages end up in spam and the whole email system is more or less centralised due to attempts at combatting the issue. Those are all user facing issues. Your ideas for client-side blocking in a federated system may be okay, I don't know. I'm objecting to the "Email has dealt with the spam issue mostly" thing; it absolutely has not.
    - ndriscoll 4y ago
      > the whole email system is more or less centralised due to attempts at combatting the issue Do the big email providers even attempt to combat spam? I got an email from booking.com yesterday that literally contains the text "This message is an advertisement." From what I can tell, Gmail hasn't maintained their spam filters in at least a decade.
zimpenfish 4y ago
> It works pretty well on email. As someone who has been running mail servers for 20 years, no, it does not. I'm sure other mail admins will agree.
- account42 4y ago
  > I'm sure other mail admins will agree. Don't be.
  - zimpenfish 3y ago
    Then I, and no doubt many others, would love the disagreers to document their setups which have defeated spam because it is still a daily problem round these parts.

debugnik 4y ago

> We've been trying that with email and spam Aren't we talking about blocking and muting known user handles? This is easy, the spam problem would be identifying which handles to block. > What happens if B sends enough to DOS A's link? Or sends CSAM and now A is committing a crime just by downloading the content? What happens if B does the same before A had a chance to block them? And why would A's client download the content after reading that B published it from the metadata? > Which increases the friction on B if they want to harass A True, but I'm afraid we already know from Twitter that B will do it anyway, aided by either fast user switching or a Tweetdeck-like interface.

zimpenfish 4y ago
> Aren't we talking about blocking and muting known user handles? This is the same as blocking known spam domains and IP blocks in email. They just switch to a new one. Which is best dealt with at the remote end since the server has a better chance of being able to identify new accounts which are related to blocked ones - Instagram even suggests this for you when you block someone: "...and any future accounts they may create". Having to do this in A's client is much more difficult because it lacks the information that would be useful. > What happens if B does the same before A had a chance to block them? A fair point.