@Gargron What do you think about the idea of #mastadon servers supporting #atproto in addition to #activitypub?
By the way, thank you very much for your work and vision! #fediverse
@Gargron What do you think about the idea of #mastadon servers supporting #atproto in addition to #activitypub?
By the way, thank you very much for your work and vision! #fediverse
@tokyo_0 @smallpatatas @Gargron @tay
Yes, this seems to be a widely spread misunderstanding. On any public social network - including not only #mastodon, but also #twitter, #threads etc. - you always can easily see posts of blocked people.
@smallpatatas @tokyo_0 @Gargron @tay
It's not misleading. They are two different things. @Gargron is correct about delivery, while authorized fetch protects against traveling via third servers. Obviously combining both provides most security (which is a misleading term here).
Of course, many people may risk havinbg a false sense of security, also in case of full defederation. Never forget: Everything you post on a public social network is, well, public.
That's exactly the point: No need to block 100m by hand. Each user can simply block the domain. Then their data won't be delivered to #meta / #threads. No admin level domain blocking needed.
Such personal attacks (as well as misinformation) which are completely unnecessary and which unfortunately I've seen multiple times from the #fedipact crowd are in my view one of the reasons of the toxicity of social media, and it seems it has spilled over even to #mastodon.
There are already people on #threads who want to be protected from the #mastodon world, and I can understand them more and more.
What about making this a better place instead?
No, in contrary, @Gargron clarified that also using user level domain blocks "stops your posts from being delivered to or fetched by Threads", which obviously prevents "#threads users to see and interact with your content".
(Of course not protecting against screenshots, data cached before you blocked, or not using authorized fetch.)
That's exactly a perfect sample for the importance of basing all these #threads, #meta, and #fediblock discussion on technical reality.
Well, this post https://tech.lgbt/@tay/111587118907388940 was literally worried specifically about #threads "which is the problem most have with the whole situation. we don't want our data fed into the Meta hellscape machinery".
And @Gargron was answering with a technical clarification that this is not the case with user level domain blocks.
https://mastodon.social/@Gargron/111587138177854666
was a direct response to
Well, the post @Gargron was responding to was a perfect example of a #threads related fear based on a technical misconception. @Gargron cleared that up.
Overall, watching these discussions, my impression is that a more solid technical foundation would be very useful.
Yea, but these "significant considerations" should be based on solid technical information and not just rumors or even misinformation about how things work.
I am full with @Gargron on clarifying technical misconceptions.
That was the reason for @Gargron follow-up in the first place.
You have to ask him, but I think because many people erroneously think that admin level domain blocks can do something user level domain block cannot do, and he wanted to clarify technical facts.
My impression is that this technical misconception is mainly spreading in the #fedipact crowd for justifying an ideologically motivated defederation.
That's a direct untruth. He says that server-level and personal domain blocks behave the exactly same way when it comes to fetching and delivering content.
What do you mean? In this post I don't say that regular users can enable authorized fetch.
It seems we are moving away from a serious technical discussion ...
@tokyo_0 @Gargron @tay Which earlier writing are you referring to?
@tokyo_0 @pieselpriemel @Gargron @tay
So far I have only heard about rumors without first hand information.
And I saw more solid arguments about post which you would expect to be not visible ending up being visible because of caching, but I don't see how this would be different for admin versus user level domain blocks, or in conjuction with authorized fetch network level blocks.
I have seen many claims that @Gargron isn't accurate, but I don't remember supporting explanations yet.
@tokyo_0 @Gargron @tay
Of course not, but an admin can enable authorized fetch without blocking an instance.
@tokyo_0 @pieselpriemel @Gargron @tay
This seems to support @Gargron explanation that admin level domain blocks and user level domain blocks are equivalent, right?
The section about "User Level Domain Blocks" says that "Blocks placed this way are affected by Authorized Fetch in the same way as server level suspensions described above."
It seems to me that there is an active hunt for finding a reason to justify admin level domain blocks.
Doesn't authorized fetch affect personal server blocks in the same way as admin server blocks?
Maybe cached from a time before the block?
This would mean that content you created before your block could be still in the wild, but your new content not.
But also here, there would be no difference between admin blocks versus users blocking a domain.
In any case, it seems both of us have no solid information, and @Gargron for sure knows better, ar least than me. So as long as I don't have other information I trust that his infos are correct.
Well, if posts are always fetched from the original source which can check blocking, then network level blocking would have no advantage over a user blocking a domain.
If however servers spread posts without checking the original server, then network level blocking would not help either, because a non-#threads-server could spread anything to anywhere.
In summary, @Gargron explanation that these kinds of blocks are equivalent seems plausible to me.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.