It uses WebTorrent for distribution between viewers watching at the same time which can temporarily help with the load on popular videos, but there still needs to be at least one source instance that's sharing the video "regularly" (for unpopular or old stuff), which ends up having the same bandwidth issues you'd get with any other video platform.
You have to actually toggle to see it but IMO it massively improves how scrolling feels.
There are a few more scrolling-related options out there on the net if there's a particular "feel" you want to go for. https://github.com/yokoffing/Betterfox/blob/main/Smoothfox.js provides a couple you can try out, and most of these custom scrolling options use msdPhysics as a baseline.
Not obscure but general.smoothScroll.msdPhysics.enabled=true is a must have IMO.
There are signing keys involved, so if someone puts up a new server but uses different keys then all sorts of federation trouble will await them.
That said it shouldn't affect the general network, just that individual server (both the communities and the users of it)
Edit: As for switching domains on an existing server, that would be equally troublesome as ActivityPub kinda relies on domains for all sorts of IDs.
jsyk, with how ActivityPub works changing the software that's running from under it will break federation with you in all sorts of subtle ways. When you pick a thing to run under a domain you're effectively locked into running that software under that domain. And of course there is some cryptographic verification as well so you change the keys (or you wipe or forget to back up the database) you may as well burn that domain from federating ever again.
On a desktop or especially laptop case, it should be equal to (or larger than) your RAM if you use hibernation (as RAM gets copied to swap during hibernation)
On my server, I set it up to be 2GBs, mostly arbitrarily. Right now it's at 500MB, but my main memory is also only 600-800MB full out of the total 4GBs available, so I'm not running out of RAM anytime soon.
Swap behavior seems to have changed a while ago, so consider reading https://chrisdown.name/2018/01/02/in-defence-of-swap.html on how it works right now. Hell, even that might be outdated nowadays. Up to date info on how swap works really seems hard to come by.
Moreover I also have my swappiness set to 0 because I don’t want stuff swapped out of memory. If I need more memory I need more memory.
I don't think swappiness has worked that way for a while now.
People aren't against companies, people are against Meta. In the wider fediverse, anyway.
A while back there was talk of Tumblr potentially joining the fediverse, and it was met with neutral to positive reactions. No idea what happened there, maybe they're still working on it, but I do not expect a "fedipact against tumblr" to gain as much steam (if any) when they decide to announce they're ready to flip the ActivityPub switch.
(no idea if my other comment got sent out, this may be a duplicate)
Your private messages are never private unless you're on a platform that specializes in private messages (Signal. Matrix, WhatsApp (if they are to be believed), XMPP via OMEMO...)
I do not agree with the people wanting to control other servers by trying to force defederating from threads. Independent admins running their own server is what the Fediverse is built upon.
As long as authorized fetch is implemented (and correctly), intermediaries can't "leak" messages out anyways. If Threads wanted to read the contents of a boost, they would have to ask your server for that, and your server can tell them to screw off.
Does kbin or Lemmy implement authorized fetch? If they don't they should start working on it. And consider enabling it by default. I know versions of Lemmy >= 0.18 can talk to GTS (which enforces AF) so there is partial support for it. And nobody runs 0.17 because of how inefficient it is, so that won't be too big of a backwards incompatibility issue. No idea how it works on kbin land here, but it should be implemented ASAP if only so that any future enforcement won't break backwards compatibility.
I have no idea if there was a native setting to disable it or if it was RES's doing but I completely forgot chat even existed.
Storage space is one issue. Bandwidth (how many TB/mo goes out the server) is another. And for any "serious" use case transcoding would also be important (so you can keep the other two down for everyone except Apple users who are stubborn to adopt VP9/AV1, and to provide multiple quality options), which unlike the other two requires powerful hardware most instances do not have.