F04118F

Does DuckDuckGo do this as well or is that a better option, privacy-wise?

EDIT: answer is here: https://www.privacyguides.org/en/search-engines/#recommended-providers

If you need to hide IP, you just use a VPN. Duh!

And Qwant is not listed on privacyguides?

For anyone wondering what "TDS" means:

Trump derangement syndrome (TDS) is a pejorative term, used to describe criticism of or negative reactions to President Donald Trump that are perceived to be irrational and to have little regard for Trump's actual policy positions.[1] The term has mainly been used by Trump supporters to discredit criticism of him, as a way of reframing the discussion by suggesting that his opponents are incapable of accurately perceiving the world.[2][3] Some journalists have used the term to call for restraint when judging Trump's statements and actions.[4][5][6]

Despite the usage of the term syndrome suggesting a medical condition, TDS is not an official medical diagnosis.[7] A 2021 research study found no evidence to support the existence of TDS among Trump detractors on the left, but instead found bias among his supporters.[8

Source: Wiki

GitOps + Renovate.

Tools that allow you to work GitOps (everything is defined in text files in Git) are:

• Kubernetes
• NixOS
• to a lesser degree, Ansible

Here's a nice starter template for running your own Kubernetes cluster via GitOps with Renovate pre-configured: https://github.com/onedr0p/cluster-template

Mostly yes, but there are some closed source services which are still good options for this specific threat model.

And I just thought the clear explanation of the why combined with the list, makes this an excellent blog to send to people who don't get it yet.

The list itself is something most of the people in this community know already, but you might want to send this when someone asks "why?"

Took a look at the specification, this is what I found:

For federated servers performing delivery to a third party server, delivery SHOULD be performed asynchronously, and SHOULD additionally retry delivery to recipients if it fails due to network error.

So they should retry. Note that should is not the same as must. So there is no obligation. There is no timeline in the spec about for how long or how often retries should be done. The wording says network error.

My interpretation: the spec leaves a lot of room for implementations to differ. Network problems don't normally last for days though. I'd guess that if your server is down for 5 minutes, you'll still receive most or everything you'd normally receive. I wouldn't trust on that if your server is offline for more than a day.