A major advantage is that this allows us to send proper cache-control headers, with responses to unauthenticated users being cacheable.

Note for people using Cloudflare that it has some pretty dumb caching behaviour so you will want to make sure to disable it for any endpoint that may be authenticated.

I don’t think I wrote down the exact behaviour but IIRC it basically ignores the Vary header. So it will serve the “unauthorized” page to future requests that have credentials. I think it will at least not cache responses with authentication if vary is included but it will cache the unauthenticated ones.

That photo seems wrong… BTRFS has a stupid allocator, it always puts data on the disk with the most space in it. So I would expect that to look like

• device 1: A C
• device 2: A C
• device 3: B D
• device 4: B D

Basically chunk A gets allocated and all disks have the same space available, so it gets put onto the first two (I don’t know the exact policy here). Then chunk B gets allocated so it goes on the two empty disks as they have the most space. Then repeat for C and D.

RAID1 with two disks is very simple. It will just put one chunk on each disk, there is no other option. With BTRFS the chunks may not be at the same offset on the disk (like they would with traditional RAID1 or I think ZFS) but one chunk will go on each.

in that is also has some striping functionality.

I think you are thinking about the RAID10 profile which is 2 copies of data striped across the available disks. IIUC RAID10 and RAID1 are identical with 2 disks (as each copy will only have 1 disk available to stripe on which is effectively no striping).

Will this fullfill my two requirements? If not do you have any other recommendations?

Yes, I think it will fulfill your requirements.

Given your setup of 2 disks and 2x replication I would probably go the same route. The other major option is just to use traditional RAID and ext4 (or your favourite other FS) on top.

• Pro: Simpler.
• Pro: More tested stack.
• Con: Less flexible. If you want to add a disk later and benefit from the software raid you will need to do conversions or copies.

It’s worth noting that defederation-zero is not a practical requirement. There are some instances that just create loads of accounts and spam communities and reply to comments in communities that you are subscribed to. Of course for most instances they don’t support this and moderator prodding can solve this. But some instances are simply hostile and exist only to spam.

I do agree that I would like my instance to be defederation-minimal. Unless the other instance is being actively harmful or refusing to moderate at all (for example not retaliating for users who are breaking community rules) I would prefer to be able to see their messages and communities. For example I don’t personally agree with blocking Instagram Threads by default. Unless they show complete inability to moderate I would prefer to have the option to subscribe available. Especially because it allows an easy pathway for people to move from Threads to other fediverse instances (although maybe less relevant for Lemmy as it is more discussion oriented rather than personal profile oriented).

I would also like to be able to see per-user instance blocking. This would be a good tool for quick fixes to poorly maintained instances or instances who’s values I don’t agree with without affecting others. It could also serve as a useful signal to the mods. If dozens of people have blocked another instance maybe it is actually quite harmful and should be defederated.