I dunno about the e-mail/web hosting analogy, at least for the purposes of thinking about possible anti-spam approaches. As I understand it, the current state of Mastodon hosting is much more like the WordPress hosting example than the e-mail hosting example, in that each customer gets their own isolated instance of the software for their domain. I think a lot of the ability to achieve larger scale spam filters and etc on email hosts comes from the fact that the actual infrastructure is shared. E.g. my impression has generally been that separate Akismet-style anti-spam services has been more successful in the WordPress context than hosting-linked solutions, and that hosting-linked solutions are generally similarly implemented as plugins anyway rather than being built into the infrastructure in some deeper way. (But it’s entirely possible that I’m behind the times on that front?) In that case, there’s nothing special about the hosting provider being the same that enables anti-spam — it’s all about creating coordination systems that are trusted by many instances and thus re-create centralized decision-making for the spam-specific slice of the content moderation problem.
the entire spam problem comes from the underlying desire to see content you didn’t have to explicitly find and request. e-mail spam is because you WANT to receive e-mail from some strangers, and it’s hard to distinguish that from strangers you’d rather not hear from. Twitter/social spam is because you WANT to see some posts from people you didn’t explicitly follow, by tags or by topic.
I think I mostly don’t understand the lines of federation within Mastodon. Is it intended that the server is the unit of community, with cross-server DMs and following, but only by individual, not by topic or thread?
I dunno about the e-mail/web hosting analogy, at least for the purposes of thinking about possible anti-spam approaches. As I understand it, the current state of Mastodon hosting is much more like the WordPress hosting example than the e-mail hosting example, in that each customer gets their own isolated instance of the software for their domain. I think a lot of the ability to achieve larger scale spam filters and etc on email hosts comes from the fact that the actual infrastructure is shared. E.g. my impression has generally been that separate Akismet-style anti-spam services has been more successful in the WordPress context than hosting-linked solutions, and that hosting-linked solutions are generally similarly implemented as plugins anyway rather than being built into the infrastructure in some deeper way. (But it’s entirely possible that I’m behind the times on that front?) In that case, there’s nothing special about the hosting provider being the same that enables anti-spam — it’s all about creating coordination systems that are trusted by many instances and thus re-create centralized decision-making for the spam-specific slice of the content moderation problem.
the entire spam problem comes from the underlying desire to see content you didn’t have to explicitly find and request. e-mail spam is because you WANT to receive e-mail from some strangers, and it’s hard to distinguish that from strangers you’d rather not hear from. Twitter/social spam is because you WANT to see some posts from people you didn’t explicitly follow, by tags or by topic.
I think I mostly don’t understand the lines of federation within Mastodon. Is it intended that the server is the unit of community, with cross-server DMs and following, but only by individual, not by topic or thread?