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).

No, it’d still be a problem; every diff between commits is expensive to render to web, even if “only one company” is scraping it, “only one time”. Many of these applications are designed for humans, not scrapers.

Scrapers can send these challenges off to dedicated GPU farms or even FPGAs, which are an order of magnitude faster and more efficient.

Lets assume for the sake of argument, an AI scraper company actually attempted this. They don’t, but lets assume it anyway.

The next Anubis release could include (for example), SHA256 instead of SHA1. This would be a simple, and basically transparent update for admins and end users. The AI company that invested into offloading the PoW to somewhere more efficient now has to spend significantly more resources changing their implementation than what it took for the devs and users of Anubis.

Yes, it technically remains a game of “cat and mouse”, but heavily stacked against the cat. One step for Anubis is 2000 steps for a company reimplementing its client in more efficient hardware. Most of the Anubis changes can even be done without impacting the end users at all. That’s a game AI companies aren’t willing to play, because they’ve basically already lost. It doesn’t really matter how “efficient” the implementation is, if it can be rendered unusable by a small Anubis update.

Someone making an argument like that clearly does not understand the situation. Just 4 years ago, a robots.txt was enough to keep most bots away, and hosting personal git on the web required very little resources. With AI companies actively profiting off stealing everything, a robots.txt doesn’t mean anything. Now, even a relatively small git web host takes an insane amount of resources. I’d know - I host a Forgejo instance. Caching doesn’t matter, because diffs berween two random commits are likely unique. Ratelimiting doesn’t matter, they will use different IP (ranges) and user agents. It would also heavily impact actual users “because the site is busy”.

A proof-of-work solution like Anubis is the best we have currently. The least possible impact to end users, while keeping most (if not all) AI scrapers off the site.

“Yes”, for any bits the user sees. The frontend UI can be behind Anubis without issues. The API, including both user and federation, cannot. We expect “bots” to use an API, so you can’t put human verification in front of it. These "bots* also include applications that aren’t aware of Anubis, or unable to pass it, like all third party Lemmy apps.

That does stop almost all generic AI scraping, though it does not prevent targeted abuse.

You don’t get control of the incoming port that way. For LetsEncrypt to issue a certificate primarily intended for HTTPS, they will check that the HTTP server on that IP is owned by the requesting party. That has to live on port 80, which you can’t forward on CGNAT.

Reminder that the license was changed to a “custom” non-free license.

Keyguard, which works on Bitwarden-compatible servers like Vaultwarden

https://ntfy.sh/

Easily set up, and easily attached to other things. Simple notifications about whatever is needed, like service health or updates, new posts on public platforms, etc. A simple curl is plenty to send and receive notifications, and it works on Android without requiring FCM (Google infrastructure).

I use mautrix/discord, it can work in both puppeting (sign into your account) mode and relay (bot account with webhooks) mode.

1. A puppeting (personal account) Discord bridge basically requires your own homeserver. You are trusting the homeserver owner / bridge host fully with your Discord account.
2. It is technically against Discord ToS. While I don’t think anyone’s been banned yet, several people have started receiving warnings that they “spammed”, most of them after sending an attachment. These warnings are on your account for 2 years, and could contribute to an account ban.
3. Voice chat is not, and probably will not be supported.
4. Do NOT bridge a “large” server. You are essentially re-hosting the chats, which can be extremely taxing for large and active Discord servers.

I use mine for a single channel in a “medium-size” server (~2k people), a friend group server, DMs, and a few channels that follow a bunch of announcement channels on other servers.

“LineageOS stan”?? The same arguments go for any custom Android rom that doesn’t ship with Google Play Services or MicroG.

“It’s always LineageOS users”

FYI, Since I personally prefer absolutely zero connections I didn’t approve of, I’m using a privacy-focused rom. I’m not even on LineageOS.

I love the complaining about privacy, after which you immediately share a google translate link. Was it that hard to find an English source stating LineageOS connects to Google?

Anyway, this doesn’t dispute any of my arguments. LineageOS connecting to Google by default does not mean it sends the same amount of data as a stock rom with Google Play Services. A user shouldn’t be discouraged in taking steps to further their privacy because it’s “not good enough”.

not actually degoogled

Aside from vendor firmware, LineageOS is mostly deblobbed by default afaik. The remaining bits that connect to google (by default) like AGPS or captive portal are significantly less information than full google play services.

try to do it in ways that provide no privacy benefit

Replacing google play services with microg might have the same security downsides as regular google play services (privileged access), however, MicroG is open source. It still connects to Google, but sends significantly less data, and you can see exactly what it sends.

Break any semblance of security model

Rooting is one example, but access to it is often left up to the user. Keeping the bootloader unlocked has some major security downsides, but they’re entirely for when an attacker has physical access. The privacy downsides of an unlocked bootloader do exist, but they’re hard to exploit even with physical access.

ingnoring all of AOSP is Google

Yes, this is something you are forced to ignore with any custom Android ROM. Graphene, Divest, Calyx, etc all suffer from the same issue. Sending data to Google and privacy is not the same as being independant from Google developed software.

purely focussing on Google

On an AOSP or LineageOS based rom without preinstalled bloat, this is almost entirely up to user choice. You can choose to only install FOSS apps without trackers, or use Aurora store and install proprietary apps. You can choose to block network access for apps with trackers, or isolate them to a work profile and kill them in the background. It isn’t good to focus only on Google, but it’s a good starting point to use a rom without standard google play services.

While I agree that a hardened and privacy focused rom is better for privacy than regular LineageOS, privacy is not black and white. MicroG sending significantly less data is better than full access google play services sending all data. Not sending data is better than MicroG. That doesn’t mean every user is able to use an entirely degoogled rom. Each person should decide for themselves what they’re okay with and what they absolutely require on their own device. When someone is trying to get some privacy back, MicroG is a great option “in the middle” where as little functionality as possible is lost while sending as little data as possible. Discouraging that someone takes steps to improve their privacy just because it isn’t perfect is not good, as that often results in someone not taking any steps towards privacy.

On the compatibility, while MicroG has some issues with specific apps, it does generally work (from what I hear from others). Not having google play services (or MicroG) can work, but it requires missing out on some google services like notifications for proprietary apps. For me personally, that’s not a big issue, as I only use FOSS apps.

Simply not having google play services installed is a massive privacy win. Any custom rom (without google) will offer that. Divest and Graphene offer some extra security features.

The compatibility can be usable if you don’t rely much on closed source apps or their notifications. If you do, you’ll need either microg or full google play services.