Ghoelian

Okay, what you explained does make sense, but not in the context of a federation event (as far as I understand, which could very well be wrong).

If B’s server sends the full response along, then C can see the contents of A’s post even though they’ve been blocked by A.

Sure, but this would only be needed if a user needs permission or something to view a post. They don’t, a post is (always, afaik?) public.

Besides, federation is not on a user level, but on an instance level. It doesn’t matter if user A has blocked user B. As long as just one person on user A’s instance does not have user B blocked, events and metadata will need to be federated. So, for public federated services, I don’t think it makes any sense to use this kind of access control.

I figured a post with a link with preview image wouldn’t be the same in terms of event as an image post. Turns out it pretty much is, but also, I checked a few posts and cross-posts across instances, all of them have an image url of the original instance, not the one I’m viewing on. So if they are individually fetching this image, they’re not using it.

Edit: I was wrong, two of the crossposts just didn’t respond to the request for activity, so I was looking at the wrong response data

You mentioned both in the same comment…

[…] NPR apparently blocks the former

I’m just saying, their employer can’t block like NPR does, because they are fundamentally different things. The one is a server receiving a request, the other is a firewall seeing encrypted packets.

Edit: the other could also be a DNS resolver that just does not resolve certain domains.

Are you sure? In your post you’re talking about fetching an image for a link preview, not an image post.

Usually, when I see an image post, the source is actually the pictrs of the source instance, so in that case I think it is federated.

You’re talking about 2 different kinds of blocking here. NPR can’t block a URL, that concept doesn’t really exist at this level. They could block ip addresses, or user agents as you mentioned.

A workplace can’t block by user agent (at least not on any website using TLS), as this header is not readable by any intermediary devices.

That’s weird. Is that how it’s supposed to work, or did they just implement it in a bad way?

I don’t think compute resources should be an issue, if anything it saves other instances resources.

As far as I understand, right now, all instances are fetching this data individually, so they all have the same compute load from this. Doing it on one and sending it along with federation should keep resource useage pretty much the same on the originating instance, and less for all others.

This would still increase bandwidth of course, but at least with all VPS providers I have used, bandwith is pretty cheap.

Some songs got renamed or put under a different artist, because I guess, the actual song is not in the MusicBrainz database

How did you manage that? If picard can’t find a song, it won’t put it in the rightmost view and it won’t be processed.

I don’t let Picard move my files, only tag and rename them, because (last time I tried) I couldn’t easily see where it was going to move the files to verify if it’s correct. I run Lidarr pretty much exclusively to sort everything correctly lol.

I suppose it should be pretty easily verifiable. Just set up a new SSID without protection and see what connects.

Might as well try it with my own TV. IIRC I never accepted any TOS either.