5 ms·

Email is a bit different from the new federations we're seeing today: there's less weaker guarantees of identity, and there's less emphasis on choosing what oth

Email is a bit different from the new federations we're seeing today: there's less weaker guarantees of identity, and there's less emphasis on choosing what other instances you federate with. In the example of Mastodon, the cost of setting up a new server is also too high to make spam effective, since you need a persistent, reachable account in order to interact with other instances on behalf of it. And the social factor counts, too, newer federations like this tend to be opposed to corporate influence in general and this makes it hard for it to get the initial foothold. Email has a lot of spam, but a federated system which keeps this in mind from the outset needn't suffer the same fate. EDIT: Incorporating the replies to my comment, I also want to mention that the lack of large, centralized players like gmail also prevents spam. If there are a lot of intances, and they're all small, then cutting one off for bad behavior is a lot less difficult. Instance admins can be held accountable for the behavior of their users.

Jasper_ 6y ago
That would imply that centralized solutions would have even less spam, since they have much stronger guarantees of identity. And yet sites like Twitter has plenty of spam. Even Hacker News gets spam! And this is not a popular place in the grand scheme of things. How is distributed identity solved in the long term? Nobody would run a server to communicate spam; that's rarely how email spam is sent these days. Most of the spam I get is from accounts hosted on GMail and Yahoo!. So the weakest link is a single server that's community-respected, but doesn't have adequate spam protection. Federation makes that much harder, because the whole point is that every server is run separately. Mastodon gets no spam today because it's smaller than Hacker News. There's relatively nobody on there.
- kzrdude 6y ago
  I'm worried how mastodon is going to scale (in terms of moderation) - maybe some instance can experient with crowd sourced moderation.
  - indigochill 6y ago
    Part of the point, as I understand it, is that moderation scales more-or-less linearly because each instance is ideally human-scale (that is, maybe having hundreds of members as opposed to millions) and responsible for its own moderation, unlike sites like Twitter or Facebook which have to pay a relatively small team of moderators to moderate millions of people's communications. There's nothing saying any particular instance will moderate, but if they don't and it becomes a problem they'll quickly find themselves cut off from federating with other instances.
- riffic 6y ago
  > How is distributed identity solved in the long term? Same way email handles it -- through the use of the domain name system. You'd expect that an a federated server with the address "https://mastodon.mit.edu/ https://mastodon.mit.edu/" would consist of those with a tie to the Massachusetts Institute of Technology (faculty or students). Your identity is provided by the system you are a member of and handled by your specific system administrator.
  - Jasper_ 6y ago
    That doesn't solve the spam problem, though? The issue from spam is that bad actors can sign up for any number of free-standing servers, without being blocked from the service as a whole. Blocking whole servers isn't the solution; that just leads to a weird scenario where you can't reach some of your contacts because they lucked out and picked the wrong server when signing up.
    - riffic 6y ago
      there's a lot of talk about object capabilities as a model to solve for this in the AP space. A lot of it goes over my head so I can't really go into details on it but there are some conference talks available where this is a topic. background info: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/ap-unwanted-messages.md https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/t... https://gitlab.com/spritely/ocappub https://gitlab.com/spritely/ocappub
jethro_tell 6y ago
Email suffers from one of it's early defining operational principals which was to be backwards compatible forever. In this way, operators still have to decide if they should accept federation with weakly identified entities or close the door and federate only with high reputation sources. To add to that, some forms of it's adoption are difficult to work around with normal methods. Mailing lists are tough, since they spoof the senders address and break dkim. And once again, the decision between allowing the old way, and just blocking anyone who doesn't have proper dkim. We see the complaints about this every time someone posts about an email server. It's hard to get the big guys to play ball. On the other hand, every time email comes up, people complain that there's too much spam.
- fragmede 6y ago
  A server operator can blacklist domains if they want, preventing sending or receiving from spamsalot.com and can do so for whatever reason, including if they feel spamsalot.com is too weakly (or strongly) federated for that operator.
  - jethro_tell 6y ago
    They can, but domains are easy to spoof, which leads us to operators having to decide to accept unsigned domains and risk bad actors getting through to the filters and milters or rejecting well meaning but unsigned email servers into federation. That's a problem that can be fixed from the get go if you design a federated system that doesn't assume all actors are charitable. The major players could cut down on a huge amount of spam by only accepting signed domains, but email wasn't designed to force all email through only it's home server, so that's not as backwards compatible as you'd like. That's not however a strict federation problem, it's more of an 'email was designed to assume everyone is a good actor, before we had much proof to the contrary' problem.
riffic 6y ago
note that you do not need a full-blown Mastodon server to participate in the AP ecosystem. There are very little barriers to entry here - one is being able to process dynamic scripts and the other is a registered domain name. I think the lowest cost solution to this would be a WordPress site on a shared host somewhere, with this plugin installed: https://wordpress.org/plugins/activitypub/ https://wordpress.org/plugins/activitypub/
upofadown 6y ago
Email is one to one mostly. So reputation should really also be based on individual entities. The normal way to make that possible is to have email clients sign messages by default with the senders identity of choice. The technology exists in the current system. We just need to activate it. This isn't a technical problem.

Jasper_ 6y ago

That would imply that centralized solutions would have even less spam, since they have much stronger guarantees of identity. And yet sites like Twitter has plenty of spam. Even Hacker News gets spam! And this is not a popular place in the grand scheme of things. How is distributed identity solved in the long term? Nobody would run a server to communicate spam; that's rarely how email spam is sent these days. Most of the spam I get is from accounts hosted on GMail and Yahoo!. So the weakest link is a single server that's community-respected, but doesn't have adequate spam protection. Federation makes that much harder, because the whole point is that every server is run separately. Mastodon gets no spam today because it's smaller than Hacker News. There's relatively nobody on there.

kzrdude 6y ago
I'm worried how mastodon is going to scale (in terms of moderation) - maybe some instance can experient with crowd sourced moderation.
- indigochill 6y ago
  Part of the point, as I understand it, is that moderation scales more-or-less linearly because each instance is ideally human-scale (that is, maybe having hundreds of members as opposed to millions) and responsible for its own moderation, unlike sites like Twitter or Facebook which have to pay a relatively small team of moderators to moderate millions of people's communications. There's nothing saying any particular instance will moderate, but if they don't and it becomes a problem they'll quickly find themselves cut off from federating with other instances.
riffic 6y ago
> How is distributed identity solved in the long term? Same way email handles it -- through the use of the domain name system. You'd expect that an a federated server with the address "https://mastodon.mit.edu/ https://mastodon.mit.edu/" would consist of those with a tie to the Massachusetts Institute of Technology (faculty or students). Your identity is provided by the system you are a member of and handled by your specific system administrator.
- Jasper_ 6y ago
  That doesn't solve the spam problem, though? The issue from spam is that bad actors can sign up for any number of free-standing servers, without being blocked from the service as a whole. Blocking whole servers isn't the solution; that just leads to a weird scenario where you can't reach some of your contacts because they lucked out and picked the wrong server when signing up.
  - riffic 6y ago
    there's a lot of talk about object capabilities as a model to solve for this in the AP space. A lot of it goes over my head so I can't really go into details on it but there are some conference talks available where this is a topic. background info: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/ap-unwanted-messages.md https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/t... https://gitlab.com/spritely/ocappub https://gitlab.com/spritely/ocappub

jethro_tell 6y ago

Email suffers from one of it's early defining operational principals which was to be backwards compatible forever. In this way, operators still have to decide if they should accept federation with weakly identified entities or close the door and federate only with high reputation sources. To add to that, some forms of it's adoption are difficult to work around with normal methods. Mailing lists are tough, since they spoof the senders address and break dkim. And once again, the decision between allowing the old way, and just blocking anyone who doesn't have proper dkim. We see the complaints about this every time someone posts about an email server. It's hard to get the big guys to play ball. On the other hand, every time email comes up, people complain that there's too much spam.

fragmede 6y ago
A server operator can blacklist domains if they want, preventing sending or receiving from spamsalot.com and can do so for whatever reason, including if they feel spamsalot.com is too weakly (or strongly) federated for that operator.
- jethro_tell 6y ago
  They can, but domains are easy to spoof, which leads us to operators having to decide to accept unsigned domains and risk bad actors getting through to the filters and milters or rejecting well meaning but unsigned email servers into federation. That's a problem that can be fixed from the get go if you design a federated system that doesn't assume all actors are charitable. The major players could cut down on a huge amount of spam by only accepting signed domains, but email wasn't designed to force all email through only it's home server, so that's not as backwards compatible as you'd like. That's not however a strict federation problem, it's more of an 'email was designed to assume everyone is a good actor, before we had much proof to the contrary' problem.

riffic 6y ago

note that you do not need a full-blown Mastodon server to participate in the AP ecosystem. There are very little barriers to entry here - one is being able to process dynamic scripts and the other is a registered domain name. I think the lowest cost solution to this would be a WordPress site on a shared host somewhere, with this plugin installed: https://wordpress.org/plugins/activitypub/ https://wordpress.org/plugins/activitypub/

upofadown 6y ago

Email is one to one mostly. So reputation should really also be based on individual entities. The normal way to make that possible is to have email clients sign messages by default with the senders identity of choice. The technology exists in the current system. We just need to activate it. This isn't a technical problem.