I used to think that there would be 1, main ‘Fediverse’ with all of the ‘big instances’ connected to each other. The recent Threads debacle has shown me otherwise.
The point of the Fediverse is that there is no one single entity, or group of entities, dominating it all.
Right now it feels like whatever the big instances do, we kind of have to go along with to be a part of anything. As the Fediverse grows, there will be more options to suit different types of users.
I think it’s fine if big instances choose not to federate with Threads. That will just create incentive for people to join other instances that do if that’s what they want. It’s not like defederating means being cut out of the Fediverse, that’s not possible.
Great design. I’m eager to see how it plays out.
I think most Mastodon instances also simply silence Threads: Mastodon users can follow Threads users, but Threads won’t fill every algorithmic timeline and doesn’t get suggested.
Unfortunately, neither Lemmy nor Kbin have such a feature, though Lemmy’s user side server blocking introduced in 0.19.0 should help a little.
I’m pro federate, but honestly, this seems fair. However Lemmy wouldn’t need it, as to see a threads post on lemmy, the person would have to @ the lemmy community in their post.
I think limiting/silencing is an excellent solution. It gives the people who want to interact with Threads a chance, while not disturbing the people who don’t.
In regards to Lemmy: I’ve seen a few Mastodon users tag Lemmy communities and creating posts here (generating some hilariously broken Markdown titles in the process), so we may see a few posts here or there. I don’t think anyone over at Threads knows what the Threadiverse is, though, so it shouldn’t cause any problems.
Yep. And the ones that do know and want to post to our communities would probably have the right intentions anyway
All true, and making this a feature would simply be implementing the inverse of the new capability… overriding an instance level block instead of imposing one not already at the server level.
I don’t think instance level blocks should be overridden. Some blocks are the result of moderation disagreements (beehaw vs lemmy.world vs exploding-heads vs hexbear), others are because of NSFW content, but there are a bunch of Fediverse servers full of pornography that would be illegal to host in many countries around the world (lolicon porn, for instance). If an administrator doesn’t want that trash on their server, they should have the ability to block it.
I think there’s a significant difference between completely blocking off a remote instance and making all interactions with said instance opt-in, and the server administrator should always have the final word. I think leaving the moderation on a separate layer like Nostr and Bluesky do it (not that Bluesky is federating at the moment) was a mistake, the result of some laudable free speech ideals that just don’t work out in the real world.
I think you only made a case for having two or more levels of instance block, that already exist. One due to objectionable/illegal material that cannot be overridden, and another for something like threads where a significant number of users may not want to be opted in automatically, or want to block it due to purely ideological, non-illegal reasons, which would effectively be put in place by automatically adding the instance block to user accounts that can be removed at any time, which arguably can already be done with minor changes. That’s essentially what dansup is doing, complete with including a command for Pixelfed instance admins to apply the optional block to all user accounts.