|
Top-level
 @jztusk @Crell I think this reply is a very good example of why that would be a problem: https://mk.aleteoryx.me/notes/9wexilu5kwnb05ot Basically, the fediverse is premised on the idea of many people running their own personal instance, and in adopting an allow-list model, we effectively make it difficult or impossible for these individual instances to participate. 22 comments
 @Raccoon @jaz @jerry @jztusk @Crell The refrain of “allowlists/blocklists are bad because it means you won’t hear from me” misses the point: This is why they are GOOD. People don’t have a “right” to talk to your instance, this is a privilege that should be EARNED. And the protection of vulnerable people on social media is more important than my ability to make sure they can see my dumb posts. This is not antithetical to the Fediverse. Choosing which instances to federate with is central to it! @Raccoon @jaz @jerry @jztusk @Crell Because I am not among a group that is a frequent target of abuse, I have the privilege of enjoying the benefits of being on an “open” instance without having to worry about the drawbacks. I will probably always prefer to be on an instance that is blocklist-based instead of allowlist-based. But many people do not have that privilege. @Raccoon Yes, who decides what to put on an allowlist/blocklist and what are the criteria they use continues to be a fraught problem with no simple solution. But I was countering the claim a lot of people make that shared allowlists/blocklists in principle -- even if "perfectly curated" -- are antithetical to the Fediverse, which I think isn't true. Some people bristle at the idea of these lists not because they think they might not be perfect, but because they want a nearly 100% open Fedi. @Raccoon I think maybe part of my confusion is not fully understanding how allowlists work. Can someone on a LIMITED_FEDERATION_MODE instance be *followed by* someone on a non-allowlisted instance? For instance (heh), limited.example is in limited federation mode with only safe.example in its allowlist. Someone on unknown.example wants to follow @ user @ limited.example. Can they do this?  @jsit @Raccoon I have a test instance that I will enable limited federation on. I would love to know if there are any big instances that do this already.  @jaz @jerry @jztusk I think we collectively need to come to terms with the fact that most people have no interest, desire, skill, or inclination to run their own anything, and will happily make it someone else's problem in return for money, ad data, or just not GAF. Less than 0.1% of people will run their own mail/Fedi/Identity/app/file server. We need to stop making fetch happen. It's not going to happen. @Crell @jerry @jztusk (Back of napkin caveat) Currently seeing one server per 500 accounts. Writ large that's 10M AP servers for 5B accounts. Several hundred million not-WP.com WordPress sites might offer an example. Value-add hosting options abound for WordPress, so it's partially self-hosted insofar as it's somewhat self-managed by tens of millions. Mix of managed, shared, and self-hosting for AP services coupled with a rich plugin framework is how I imagine adoption could be supported.  I think it's better to come up with better tooling that lets a small admin set up and maintain their trust relationships, and just make sure that they know that part of running their own instance means spending some time on that. The street buskers in my city take Swipe. That's the model I like  so, quarantining new instances (increased scrutiny / aggressive automatic moderation / keyword flagging) after which they would be put on either block- or allow-lists? this would (theoretically) not preclude small instance participation, and would increase cost/difficulty for bad actors. different instances could have their own metrics/rules for this, as you say giving a variety of perspectives on the new one's behavior then the decisions of known/old/large ones can be weighted by everyone to make their own decisions this leads logically to some kind of web-of-trust / instance-reputation-scoring system down the line. this can be both good and bad, but if surfaced somehow could serve as a direly needed instance selection aid for new users. ie: example.net is aggressively blocking this type of behaviour, but is above average blocked by others on this other metric I *so* want to come up with an "algebra of trust", where we can say "I trust entity X, but only to post", and "I trust entity Y, and anybody they trust too", and let the computer figure out each individual "do I trust A to do B?". I haven't formalized it at all, and there's a risk of being computationally expensive, and someone would have to do the specialization for Mastodon, but I'd love to see it. @jztusk @jaz @jerry You're trying to solve a human problem with math. That is doomed to failure, no matter what the crypto-bros keep selling. All human systems require human maintenance and decision making. Assisted, maybe, but never, ever think you can replace human decision making about human activities. one could make the argument that this would be a machine only enforcing the decisions made by a human, like a very advanced filter The humans set the base rules. Have you ever unwrapped the certificate chain for an HTTPS-transmitted web page? We're doing stuff like this right now, on massive web scale |
Gregory's Server
@jerry @jztusk @Crell
Why not both? Some servers can run open federation, some can run allowlist-only, some can run in quarantine-first mode, and over time I'm sure we'll see shared lists, reputation signals, and trusted upstream servers to help manage the onboarding/allowing.
"Disallow all, but allow all servers already allowed by x, y and z" is one way to approach.
Almost none of the asks I've seen are either/or propositions, they are generally admin options to enable or not.