@kirby@DutchBoomerMan@paula@PeachySummer Locking the access to activities, basically signed fetches on steroids since the key of fetching actor isn't even attempted to be fetched on their side. Bug or not, but I've still managed to workaround it on my side. Husky_1704910987757_LK4QACXKH4.…
@kirby@DutchBoomerMan@paula@PeachySummer If you have regular authorized fetch mode enabled, the instance checks the signatures of incoming GET requests on objects and fetches your internal.fetch signature if there's none in its database. If you disallow viewing local statuses in adminfe, I think what happens is that authorized fetch mode gets implicitly enabled plus your instance just stops attempting fetching signatures of unknown actors that request objects. How I fixed it on my side is a trade secret but if you have an idea how federation works, I think you'll figure it out.
@mint Okay so, I've never looked that close at how authorized fetch behaves, but I have one question, if anybody here is familiar with the behavior....
Originally, the big idea of shared inboxes was that, if you have Server A, Server B, and Server C, and a user on Server A has 1,000 followers on Server B, and 1,000 on Server C, then Server A is delivering to 2,000 people by making two /inbox requests.
My initial understanding of signed fetches is that now Server A is going to do something (the same thing?) to inform these other two servers that there's a status to fetch, and then Server B and Server C are now going to sign 1,000 requests each and make 1,000 HTTP requests that have to hit Server A's backend and cannot be cached, each? @DutchBoomerMan@paula@kirby@PeachySummer
@r000t@DutchBoomerMan@paula@kirby@PeachySummer There's no informing about a status to fetch aside from regular federation flow when your server fetches a missing post in thread's context. But yes, with authorized fetch there's no way to cache responses for incoming fetch requests aside from caching objects themselves internally and immediately returning them after checking signature.
@mint I've noticed a repeating pattern in the github threads for these features (the current one is a flag allowing/disallowing quoting statuses), and it's basically "oh we know this can't be enforced, but once the feature's added to every software suite, we can seek out and punish instances that make the decision to bypass it"
and we're right back where we started with, anybody worth hiding something from isn't going to make a huge spectacle that they've gotten it anyway, they're just going to keep quiet and let you think you're a big winner
@PurpCat@DutchBoomerMan@paula@kirby@r000t@PeachySummer@mint Always remember how they nagged twitter to combat "hate speech" only to bitch and complain they also got automatically flagged for saying "faggot" or "tranny", instead of it just affecting their enemies.
Add comment