Hell yeah! 10x speed improvement for free!

What I’m noticing more, is that you can keep a consistent 11.4MB/s, this feels relatively close to what you’d usually pull through a 100mbit/s link (after accounting for overhead). If that’s the case, it shouldn’t matter how the NFS client decides to chunk the data, for how much throughput there is to the NAS. Which means you’re looking at a broken NFS server that can’t handle large single transmissions.

If it’s not the case, and you’ve got a faster network link, it seems that the NAS just can’t keep up when given >2gb at once. That could be a hardware resource limitation, where this fix is probably the best you can do without upgrading hardware. If it’s not a resource limitation, then the NFS server is misbehaving when sent large chunks of data.

Basically, if your network itself (like switches, cables) isn’t broken, you’re either dealing with a NAS that is severely underspecced for what it’s supposed to do, or a broken NFS server.

Another possibility for network issues, is that your proxmox thinks it has gigabit (or higher), but some device or cable in between your server and NAS limits speed to 100mbit/s. I think it’d be likely to cause the specific issues you’re seeing, and something like mixed cable speeds would explain why the issue is so uncommon/hard to find. The smaller buffers more frequent acknowledgements would sidestep this.

Do note I am also not an expert in NFS, I’m mostly going off experience with the “fuck around and find out” method.

Sounds like a band-aid fix to a completely different problem. If NFS is timing out, something is clearly broken. Assuming it’s not your network (though it could very well be), it’s likely the Synology NAS. Since they’re relatively closed devices afaik, I sadly can’t help much in troubleshooting. And sure, dumping 25GB on it all at once is heavy, but it should handle that, being a NAS.

Personally, I have nothing against crawlers and bots

If they’re implemented reasonably, web crawlers aren’t the issue. The problems with them mostly stem from laziness and cost cutting. Web crawlers by AI comapnies frequently DDoS entire services, especially Git forges like Gitlab or Forgejo. Not “intentionally”, but because these crawlers will blindly request every URL on a service, no matter the actual content. This is cheaper for the AI company to implement this way, and scan through the data later. But this also leads to the service having to render and serve tens of thousands of times as much content as is actually present. They are made to try and hide themselves doing so, which is the biggest reason we see “modern” PoW CAPTCHAs everywhere, like Anubis or go-away.

Robots.txt used to work, because search engines needed there to be an “internet” to provide their services. Web crawlers pre-AI were made knowing that taking down a service made another website go down, which lessened the overall quality of search results.

I’ve had LLM webcrawlers take down my whole server by DDoSing it several times. Pre-LLMs, a git forge would take maybe a couple hundred MB of RAM and be mostly idle while not in use. Nowadays, without a PoW CAPTCHA in front, there are often over 10.000 active concurrent connections to a small, single person Git forge. This makes hosting costs go through the roof for any smaller entity.

Matrix (Synapse with Element) can be self-hosted for free, though they have optional paid plans for enterprises. The main goal of Matrix is federation (connecting with other servers), though this can be turned off completely. This is probably the most “business” look/feel you can get fully FOSS, if that’s what you’re looking for.

XMPP has more clients/servers, and is more for the technically oriented end user. I can’t really give recommendations here, as I haven’t extensively used XMPP.

Spacebar (formerly Fosscord) is a Discord clone (API compatibility as a goal) that can be selfhosted.

I’ve seen many default docker-compose configurations provided by server software that expose the ports of stuff like databases by default (which exposes it on all host interfaces). Even outside docker, a lot of software, has a default configuration of “listen on all interfaces”.

I’m also not saying “evil haxxors will take you over”. It’s not the end of the world to have a service requiring authentication exposed to the internet, but it’s much better to only expose what should be public.

UFW works well, and is easy to configure. UFW is a great option if you don’t need the flexibility (and insane complexity) that manually managing iptables rules offers,

The job of a reverse proxy like nginx is exactly this. Take traffic coming from one source (usually port 443 HTTPS) and forward it somewhere else based on things like the (sub)domain. A HTTPS reverse proxy often also forwards the traffic as HTTP on the local machine, so the software running the service doesn’t have to worry about ssl.

Be sure to get yourself a firewall on that machine. VPSes are usually directly connected to the internet without NAT in between. If you don’t have a firewall, all internal services will be accessible, stuff like databases or the internal ports of the services you host.

The version from their F-Droid repo, SchildiChat[f], has no Google libraries. The version from the playstore includes proprietary blobs to support Firebase Cloud Messaging (Google notifications system). Exodus may be misidentifying this as “Google Admob”, which is not present in the app.

Or the service. Software that goes out of its way to ensure you paid, and poses limitations on the paying customer. Like always-online DRM for video games.

The difference is what code runs on your device. If proprietary libraries are included, F-Droid won’t build it, and it’s not allowed in their repository. There’s a lot to say about whether a FOSS app that relies on proprietary network services is truly “free”, there’s no arguing that an app with proprietary code blobs is “free”.

Take for example an app like NewPipe. The application itself doesn’t include proprietary code, but it contacts YouTube, a proprietary Google service. With the app itself being open source, you can tell exactly what it is doing on your device, and what information is sent over the network. Comparing that to something like Signal, which includes proprietary Google libraries, you’d have to decompile and reverse engineer it to try and figure out what it’s doing.

If you have a FOSS library that interacts with Google Play Services or microG to enable FCM, it would (probably) be allowed on F-Droid. (I’m not on their team, I can’t make a definitive statement about this).

“No Google Play services” falls under “app must be FOSS”. The average publicly developed open source app should not have much trouble getting into F-Droid if the developer wants to. Google Play services consists of several components, one of which is a proprietary library included in apps using it. If your app includes proprietary code, it is not FOSS.

If Signal decided a build without proprietary blobs isn’t worth it, they’re not getting into F-Droid. Forks of Signal exist that remove the Google Play services build requirement, those are in F-Droid.

The documentation you were looking at might’ve been the Matrix specification.

There is documentation on how to host a Matrix server, I’d honestly recommend using containers (maybe docker compose) for this one. It can definitely be confusing setting up a service like a Matrix homeserver for the first time.

As for other people finding it, you can (and should) make your homeserver invite-only. It’s also possible to disable federation, which makes the server self-contained. It will not accept incoming connections from other servers, nor make outgoing connections to other servers.

This does mean everyone you want to talk with has to be on your homeserver. There are probably better options available if you want to avoid Matrix’ federation issues, like Spacebar.

Web push for notifications. Sure, there’s privacy implications, but it’s already near universal. There’s other options like ntfy.sh if you’re not limited to existing infrastructure. UnifiedPush also works well as a protocol for push notifications.

Everything else can be handled in-app. Password reset will have to be done by an admin, though it’s completely doable for a small selfhosted service.

Some of the downsides OP listed may or may not always apply, but there are always downsides. Either you have to set up your own email server (with extra maintenance burden), or your “selfhosted” app suddenly relies on third party infrastructure, like your email provider (or those of other users on your instance).

Firefox is able to do this for basic PDF annotations. It’s not very extensive, but it’s very simple to use (and you probably already have it installed).

Personally I have seen the opposite from many services. Take Jitsi Meet for example. Without containers, it’s like 4 different services, with logs and configurations all over the system. It is a pain to get running, as none of the services work without everything else being up. In containers, Jitsi Meet is managed in one place, and one place only. (When using docker compose,) all logs are available with docker compose logs, and all config is contained in one directory.

It is more a case-by-case thing whether an application is easier to set up and maintain with or without docker.

“jellyfin isn’t immune to security incidents”

Well, no software is. The difference is that Plex just leaked data of all their users, where Jellyfin can’t, because they don’t have this data.

IRC does not have any federation, and XMPP does it in a completely different way from Matrix that has unique pros and cons.

IRC is designed for you to connect to a specific server, with an account on that server, to talk to other people on that server. There is no federation, you cannot talk to oftc from libera.chat. Alongside that, with mobile devices being so common, you’d need to get people to host their own bouncer, or host one for nearly everyone on your network.

XMPP federation conceptually has one major difference compared to Matrix: XMPP rooms are owned by the server that created them, whereas Matrix rooms are equally “owned” by everyone participating in it, with the only deciding factor being which users have administrator permissions.

This makes for better (and easier) scaling on XMPP, so rooms with 50k people isn’t that big of an issue for any users in that room. However, if the server owning the room goes down, the whole room is down, and nobody can chat. See Google Talk dropping XMPP federation after making a mess of most client and server implementations.

On Matrix, scaling is a much bigger issue, as everyone connects with everyone else. Your single-person homeserver has to talk with every other homeserver you interact with. If you join a lot of big rooms, this adds up, and takes a lot of resources. However, when a homeserver goes down, only the people on that homeserver are affected, not the rooms. Just recently, matrix.org had some trouble with their database going down. Although it was a bit quieter than usual, I only properly noticed when it was explicitly mentioned in chat by someone else. My service was not interrupted, as I host my own homeserver.

The Matrix method of federation definitely comes with some issues, some conceptually, and some from the implementation. However, a single entity cannot take down the federated Matrix network, even when taking down the most used homeservers. XMPP is effectively killed off by doing the same.

Being able to choose the OS and kernel is also important. I would not want my hypervisor machine to load GPU kernel modules, especially not on an older LTS kernel (which often don’t support the latest hardware). Passing the GPU to a VM ensures stability of the host machine, with the flexibility to choose whatever kernel I need for specific hardware. This alongside running entirely different OSes (like *BSD, Windows :(, etc) is pretty useful for some services.

Same here, though more out of lack of control over the host. Libvirt works on basically any distro, and you can easily configure whatever Linux distro you like best for running it. I can’t configure my boot process the way I want on Proxmox (at least not without learning/sidestepping its “convenience” tools/setup).