Apparently not many people believe me when I say that "normal" users using the "block this domain" option, is functionally just a mute....
There's gonna be LOTS of very mad people when they find out for themselves that meta/Threads can still see their posts....😬🤦♂️
To actually block Threads, you have to be on an instance that actually blocks them. As of right now, the biggest instance that blocks Threads is masto.to
So all this talk most of you are doing, means absolutely nothing because the majority of you are still federated....
@BeAware If I'm on an instance the blocks Threads, and I post something, and my account is followed by someone on an instance that does not block Threads, and my follower boosts my post, then anyone on Threads following my follower will see my post (assuming the day has come when messages flow from Mastodon to Threads). And that Threads account can then boost it on Threads and my post, from a Mastodon Threads blocking instance, can then even go viral on Threads.
@Jerry hmm. I don't think so, because if it's like a normal activityPub instance, it would honor the block and the boosted post is a direct relay of the post from the original server, so blocks should be honored with boosts.
"Quote posts" however, arent the same and could be relayed to Threads.
Boosts are block protected because of the way it's built into the code as far as I'm aware.🤷♂️
You say If it’s like a normal activitypub instance, but firstly there’s the big if there, and secondly that assumes there is such a thing as a normal instance.
I’d say the whole point of a distributed system like this is to allow different instances to operate differently, not to be all under the same umbrella like the centralized social media platforms.
So basically, it’s considered a feature that what you’re talking about doesn’t really exist.
Everybody needs to realize that anything they post on this platform is effectively public to anyone who wants to access it, including #threads
It’s like saying everybody obeys gun laws since I’ve never been shot.
No, this is important because a lot of people in this platform don’t realize how tenuous the privacy controls actually are. We really need to emphasize that so much on this platform is based on good faith expectation instead of actual engineered control.
People need to know how little guaranteed privacy they have here because people rely on the system that isn’t actually nailed down.
@volkris@Jerry sure, but what I'm saying is exactly how the standard handles it and how threads would need to handle it and why that would be, and you're dismissing it like it's not the case, but it is.
I feel we're going in circles. You're stating that we need people to understand, yet you're denying things that are fact, completely doing the thing you're saying we shouldn't do...
@BeAware@Jerry Then they should. Keeping it disabled is being actively dumb, unless you have a very good reason to. It's default on most other fedi implementations by now.
@privateger@BeAware@Jerry I'ma keep it 100 I have seen like 2 instances with it enabled out of hundreds. It might be the default in your circles, but it's definitely not universal
@linus@privateger@Jerry facts. Doesn't help that it's a mastodon feature that's not native to ActivityPub, afaik. Which makes it so that devs from other projects have to look how mastodon is doing it before implementing it themselves.
@BeAware@linus@Jerry This is true for like 50% of ActivityPub at this point. Mastodon doesn't respect half the specs of it, this is the reason migrations suck as much as they do.
However, nothing about Authorized Fetch is special or Mastodon specific. The important part is that ActivityPub objects don't include context by default anymore with it, they only contain references to data instead. Instances have to request data from the source instead to resolve the data, while identifying themselves using their signature on every request. That's all it does. Blocked instances get denied by the source, obviously.
Proper implementations handle it gracefully, because all it really does is add one more step that gets handled automatically by your parser. Extremely badly-made ones don't.
Even Lemmy supports it nowadays, I can't think of any commonly used service that doesn't.
Authorized Fetch isn't fancy. It just does it's job. I don't think you can even see whether it's enabled as user, it's only relevant for instance to instance communication. It sucked in 2021, but a lot happened since that.
@BeAware@Jerry@linus .social doesn't because they can't risk any form of breakage.
It's a trade between making your blocks actually do something or maybe potentially breaking federation of a bad fedi implementation. I choose user safety over numbers.
Without it it's perfectly possible for abusers to reply to a post from your instance, federating those replies to everyone, with the only person not seeing abuse being you because your instance blocks their incoming federation. I think that's unacceptable.
Add comment