mstdn.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A general-purpose Mastodon server with a 500 character limit. All languages are welcome.

Administered by:

Server stats:

17K
active users

The Mo :verified:

URGE YOUR SERVER ADMINS TO BLOCK THE THREADS.NET DOMAIN

A PERSONAL BLOCK IS NOT THE SAME NOR IS IT ENOUGH

@Chromino
> A PERSONAL BLOCK IS NOT THE SAME NOR IS IT ENOUGH
A personal block behave the same as an instance wide block

@Jain@blob.cat @Chromino@mstdn.social
(Edit: Reading The Verge's
article on the recent moderation changes, that's not good. That's not good at all. Yea, even though my opinion hasn't changed, it's just sad to see even the fake appeal of making a good community disappear. Facebook has fully acknowledged its fate of being the Cult of Shrimp Jesus and the hub of rightoid boomers that die from drinking raw milk, and whether or not anything really changed, it is now fully open to us marginalized folks that we're not safe there.)

Imo, a year earlier, I would push for mass-blocking Threads due to how potent the threat of EEE could have been during this time. Now, even though I still proudly recommend blocking Threads due to a distaste towards Facebook alone, I don't feel we should look down upon others for not doing the same. It's moreso how poor moderation inevitably becomes with large for-profit communities. Bluesky didn't ban
one user, but the wider community was worse off because of it. Same goes for Misskey.io, which is a hotbed of disgusting pedo art, and mastodon.social, which is bot-infested. Plus, I feel we shouldn't get too mad when people don't want to lose the very connections that have been meaningful for them. It's a major reason why until Bluesky went mainstream, Twitter continued to be a major art hub well into its dark age.

Digital photo collage of Meta logo and hate speech bubbles.
The Verge · Here are some of the horrible things that you can now say on Instagram and Facebook
More from Richard Lawler

@Jain Are you sure? Without AUTHORIZED_FETCH, I think you're right, but with AUTHORIZED_FETCH enabled, an instance-wide block works differently, since it also blocks outgoing communication with that instance.

@Chromino

@Jain@blob.cat @Chromino@mstdn.social pretty sure it isn't? if you enforce signed fetches, instance-wide blocks prevent the remote instance from fetching activities. i don't think that's a feature on the user-level.

@privateger @Chromino @mezzodrinker
Both of you do not differentiate between blocks and instance settings.
An Instance blocked by a user should have the same behavior like an instance blocked by the instance.
Signed fetches do have an impact, i also agree with your statements, and also the User cant enable signed fetches but the effect of enabling signed fetches should also be the same for both way to block instances

@Jain @Chromino @privateger It should, yes, but the status quo is that it isn't. So your initial statement that user blocks behave the same way as instance blocks is incorrect if we account for signed fetches.

@mezzodrinker @Chromino @privateger i say it should because i cant guarantee that every software has the same behavior out there.
As i said, clearly you dont differentiate signed fetches between blocks.
Let me clarify it once again:
User blocks and instance blocks still have the same behavior, as i said.
The result of Blocks (doesnt matter which ones) is different for instances with signed fetches enabled and for those who dont, of course.

My initial statement was the first one and i dont see that wrong in any way since imho it never was about signed fetches in the first place, it was about user blovks and instance blocks

@Jain Just to make sure I don't misunderstand what you're saying: By saying "clearly you don't differentiate signed fetches between blocks", are you trying to say that I am saying that signed fetches and blocks are the same thing, or are you trying to say something different? Because I genuinely can't tell at the moment.

@Chromino @privateger

@mezzodrinker @Chromino @privateger @gabboman
shit im talking bs, sorry
i somehow had in mind that instance blocks on any requests can be done but the only way to block an instance truly is via signed fetches...
Without signed fetches there is a trust that the other server does not show posts for blocked users but there is no way that the other server would discard posts since instance blocks are not propagated.
User/Instance blocks against users and are federated, user/instance blocks against instances are only local, and the only way to verify that truly is signed fetches...
:blobcatgooglynotlikethis: sorry, today im stupid.
gabboman's comment about the profile somehow clarified my mind

@Chromino @privateger @mezzodrinker @Jain truth be told yesterday I was talking bs about gpu technology so its ok.

@privateger @Chromino @mezzodrinker @Jain update: mastodon does block the STATUSES (posts) but not your profile

@Jain @Chromino @privateger personal instance block wont stop threads to ask for your profile and your instance to give info of you.

I had to code this thing in particular for threads in wafrn

@Chromino@mstdn.social I think you're on one of the few instances that doesn't block threads.net