Mima-sama@BeAware Uhh I think you've gotten it fundamentally wrong here 
Whether your instance's posts appear on the blocked instance or not doesn't depend on the blocked having #AuthorizedFetch, but rather your instance having AF. That instance can still fetch your posts because your instance doesn't check if the request is signed (so an instance can sign all their fetching but still not enable AF, which is what vanilla #Misskey currently does) and from which instance the fetch request is coming from (hence the "authorized").
Threads already defederates from instances that don't sign their fetching (by design because they've enabled AF), but they don't care if an instance has enabled AF (it's that instance's problem to deal with posts still appearing in Threads).
The problem (I have) with AF is that it's pretty much just #securitytheater. The documentation doesn't seem to account for this possibility, but if your adversary has enough money for some cheap domains and is well-versed in how #ActivityPub works nowadays, then it's trivial for them to forge signatures to look like their fetches come from an innocent server, therefore effectively bypassing the check and allowing the blocked to get your posts into their instance. This is already being done in the wild (with the #Soapbox developer doing this to bypass Threads' fediblock being the most infamous recently).
It also complicates AP implementations because now you have to deal with more cryptography with all that signing and verifying of requests. And signing alone does have a significant impact on performance. It's impossible to create a 100% compatible AP implementation from the spec alone without looking at Mastodon's implementation. That's where the #EmbraceExtendExtinguish or #EEE comes to play.
So overall it's the overeagerness of #MastoAdmins in adopting AF or #SecureMode without understanding the compatibility and performance implications that brought us to this mess today.
Whether your instance's posts appear on the blocked instance or not doesn't depend on the blocked having #AuthorizedFetch, but rather your instance having AF. That instance can still fetch your posts because your instance doesn't check if the request is signed (so an instance can sign all their fetching but still not enable AF, which is what vanilla #Misskey currently does) and from which instance the fetch request is coming from (hence the "authorized").
Threads already defederates from instances that don't sign their fetching (by design because they've enabled AF), but they don't care if an instance has enabled AF (it's that instance's problem to deal with posts still appearing in Threads).
The problem (I have) with AF is that it's pretty much just #securitytheater. The documentation doesn't seem to account for this possibility, but if your adversary has enough money for some cheap domains and is well-versed in how #ActivityPub works nowadays, then it's trivial for them to forge signatures to look like their fetches come from an innocent server, therefore effectively bypassing the check and allowing the blocked to get your posts into their instance. This is already being done in the wild (with the #Soapbox developer doing this to bypass Threads' fediblock being the most infamous recently).
It also complicates AP implementations because now you have to deal with more cryptography with all that signing and verifying of requests. And signing alone does have a significant impact on performance. It's impossible to create a 100% compatible AP implementation from the spec alone without looking at Mastodon's implementation. That's where the #EmbraceExtendExtinguish or #EEE comes to play.
So overall it's the overeagerness of #MastoAdmins in adopting AF or #SecureMode without understanding the compatibility and performance implications that brought us to this mess today.
