Tired: silently blocking half the fediverse.
Wired: There is no legitimate reason for instance admins not to be transparent about what instances they're blocking.
Woke: With good enough user-level blocking tools, there is no legitimate reason for instance-level blocking, regardless of transparency.
@kevin_redacted
don't know if I fully agree, but I do see where you are coming from-
I think there is a chance for something different here-
as@Rushyo@mastodon.social said
"As long as people are on large servers that federate openly with other instances, I'm noticing it's hard for them to understand Mastodon's potential for doing things differently through de-centralization.. . .Selective syndication allows for very specific communities, with standards and norms rather than hard rules"
@kevin_redacted what about if instances instead have a default blocklist for new users, which those users can then change if they want?
@esselfortium I'd be ok with that, I guess.
@kevin_redacted Hm. You know... The database query for exposing blocked domains is trivial. It wouldn't be all that difficult to expose that list, optionally of course, on maybe the 'about' page.
@kevin_redacted I will ponder that patch
@sungo One of the other implementations, I believe gnu social, already implements that, but if IIUC, gargrom refuses to implement it, because he considers lack of transparency on the issue a feature, not a bug. I'd be very curious to see what he said if you submitted a patch.
@kevin_redacted I'd make it a site admin toggle. That's where the patch becomes obnoxious, sadly.
@sungo I don't think it should be a site admin toggle, personally.
@kevin_redacted Yeah but I think it's the only way to get that patch in. Once the main codebase settles down, it might be worthwhile to maintain a more transparent fork. Or at least a patchset that admins can apply on their own
@sungo The impression I've gotten is that his heels are dug in so far on this and other issues, that a fork will be necessary regardless.
@kevin_redacted It's possible. I have some security concerns too that I'm pretty sure won't get fixed. (It may not be possible to fix them easily.)
After digging through the codebase for the last two days, I am displeased and not sure what I'm going to do about it.
@sungo Nice. Are you going to submit it to gargron?
@kevin_redacted Probably. I have to clean it up so it meets the contribution guidelines.
@kevin_redacted blocking could exist for if you were trying to maintain an org level, but for public consumption....i don't think i'd block with fart.
@kevin_redacted Is this blocking happening to Mastodon and other types of GNU Social instances?
@gideonro It's primarily the Mastodon flagship instance mastodon.social which blocks other instances.
@kevin_redacted I see. Thanks for clarifying. Is there a record somewhere of this to help people decide where to affiliate? Or is that part of the point you're making?
@gideonro Yes, that's part of the problem - the lead mastodon developer is block-happy and is resistant to transparency re: blocking - some other implementations actually directly expose their block lists so they can be programmatically checked, but he's resistant to implementing that.
@kevin_redacted People will likely vote with their feet, I suppose. That requires that people understand these subtleties, however, which isn't always a safe assumption.
@kevin_redacted I think things are a bit different: in development discussions I know the idea of blocked-instance transparency has come up and been met with approval. at this point it seems much more likely to be an availability thing
@kevin_redacted i've been grumbling about the lack of user-side instance blocking for months now