Great point, I should be more explicit in the article. On Lemmy, it would look like a couple of things:
today, another instance's request to federate is accepted unless it's explicitly blocked. This means that bad actors can get away with stuff until they're discovered and blocked (although it makes it easier for good actors to federate). Consent-based federation turns that around: a request to federate isn't accepted unless it's approved. One way an instance admin could decide whether or not to approve a request is to look at FediSeer to see what other instances are saying about the requestor.
at the individual level, it would mean that people would start out by participating in local communities (and maybe even just seeing posts from their instance, not sure about that), and could then choose to have their posts federated out
That sounds like it punishes small instances... a lot. What would starting an instance look like? Do you start with a huge list of servers to inspect and approve?
For new instances, the easiest thing is to start with the list of an instance that the kind of moderation you agree with. If I were starting up an instance in the Lemmy world, I might go with the current federation list of lemmy.blahaj.zone or beehaw.org (although others might make differnet choices), in the Mastodon world I might use awoo.space as a starting point.
There's certainly a need for tools to make this more scalable. "Recommended lists" are a likely next step; there isn't much software support for this yet, but it's similar enough to blocklists that they're also fairly straightforward; it would be up to the new instance admin to decide how many to inspect or whether just to trust the list. And tools are also needed to address the challenge in the other direction: how do existing instances decide whether or not to accept the request? Instance catalogs like fediseer can help. Another possibility that I mention and link to in the article is "letters of introduction"; federations of instances (which I'll talk about in the next installment) are another.
Great point, I should be more explicit in the article. On Lemmy, it would look like a couple of things:
today, another instance's request to federate is accepted unless it's explicitly blocked. This means that bad actors can get away with stuff until they're discovered and blocked (although it makes it easier for good actors to federate). Consent-based federation turns that around: a request to federate isn't accepted unless it's approved. One way an instance admin could decide whether or not to approve a request is to look at FediSeer to see what other instances are saying about the requestor.
at the individual level, it would mean that people would start out by participating in local communities (and maybe even just seeing posts from their instance, not sure about that), and could then choose to have their posts federated out
That sounds like it punishes small instances... a lot. What would starting an instance look like? Do you start with a huge list of servers to inspect and approve?
For new instances, the easiest thing is to start with the list of an instance that the kind of moderation you agree with. If I were starting up an instance in the Lemmy world, I might go with the current federation list of lemmy.blahaj.zone or beehaw.org (although others might make differnet choices), in the Mastodon world I might use awoo.space as a starting point.
There's certainly a need for tools to make this more scalable. "Recommended lists" are a likely next step; there isn't much software support for this yet, but it's similar enough to blocklists that they're also fairly straightforward; it would be up to the new instance admin to decide how many to inspect or whether just to trust the list. And tools are also needed to address the challenge in the other direction: how do existing instances decide whether or not to accept the request? Instance catalogs like fediseer can help. Another possibility that I mention and link to in the article is "letters of introduction"; federations of instances (which I'll talk about in the next installment) are another.