Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've partially degoogled, and it was certainly influenced by these kinds of discussions.

The most compelling reason I have found for degoogling is to make the question "what happens if they ban me?" get the anwser "nothing much". The next most compelling reason is to protect the world from their influence. i.e. take my influence amongst my family and peers and use it to steer another small part of the world away from googlopoly.

So I use firefox (of course Mozilla is massively dependent on google for money), and I use DDG, and I have fastmail.

My phone is Android, yet its replacable and correctly backed up (not google auto backups). I try and avoid google apps and services.

I barely use other google services.

With the exception of my day job. Currently we are a GCP shop, for good reasons. At some point in the hand wavy future we should be able to hop clouds as we will though.



Same. I'm at a similar position except I haven't quite got my Android situation sorted out. Google photos is really quite good. And maps too.

Migrating from Gmail to fastmail was really quick and easy and I wish I had done that sooner. Except I think I'll be finding websites registered with my old Gmail address for the rest of my days.


Another compelling reason is to avoid actively contributing to their ad ecosystem, which is ultimately paid for by the users and businesses that (have to) rely on the products because they are the biggest player in the market.

One of many examples is how Google pushes for advertisers to bid on their own keywords, so you have the same result as the first ad and organic page. Is that really necessary?

I'd rather get a discount or better service than click on an ad, performance marketing makes companies think otherwise because it's more difficult to measure.


I wonder if all the people leaving Google for Fastmail will make Fastmail the next Google. It's better to diversify accounts like that, especially in the case of email, which (currently) works across providers, despite attempts by Google and Protonmail to lock users in.


On this principle I was actually with migadu for a long time - only recently did I switch to fastmail.

Long story short migadu are not trustworthy, they fail to assist support tickets and don't notify their clients of outages where mail was deleted - blaming the client for not regularly looking at their homepage XD.

I did look at many smaller providers, I was particularly interested in finding a uk based one. Unfortunately my requirement for a wildcard inbox with true blacklisting and sender rewriting narrows the field considerably.

If fastmail drops me I'll be back to hosting my own and all the PITA that is. Or more likely writing an interface on top of some business mail solution.


Thank you for your criticism here (offtopic though), but we have never had an outage where mail was lost. Where did that comment come from? I am sorry for that bitterness, but I don't think we deserve it.

I rather think the issue here was that your regexes which were supported on our legacy system were not all converted to the new system during migration. This was something we did notify our users about via email and our home page. Not sure what more we could have done there.

Nevertheless, that has nothing to do with being "trustworthy".


Whilst this is high risk for a flamewaresque HN policy violation I'm going to attempt a response.

When a very important email never arrived I suddenly realised I hadn't been receiving email for two days. Jumping onto the migadu site I found a brand new UI with all my regexes gone and my email ingestion broken. So I patch it up quickly and send a support ticket.

In short the response to the ticket was: "we had a storage layer failure [...] we could not serve all the requests [...] The catchalls and aliases have been a consequence - hence no announcement" (announcement is a reference to me asking why I wasn't emailed to tell me).

Unfortunate things happen, I get it. However. When they do, notifying clients should be a high priority.

Combine that with some previous and subsequent tickets that were closed without resolution and I have a pattern of behaviour that is completely absurd for the provider of a vital service.

The account that given in your post is at odds with what I received from the support team - this is even more evidence to me that migadu is not the right company to be responsible for my mail.

I also feel its important to highlight your claim "we have never had an outage where mail was lost". When an email responds to a sender indicating that a user does not exist the result is the email being deleted. Many terrible systems in business do this silently. The fact that migadu allowed this failure mode without a mitigation (and in your example, deliberately) is assuredly mail loss. What else could be done? It could be rejected but still saved (bulk disk writes with simple metadata - anything) so that intended receivers can be notified which senders now think they don't exist.


No risk of flamewar, I genuinely want to know your view, not defend ourselves in public. If we messed up, knowing where and how helps not to repeat it.

I agree we could have done that better, however an announcement was made via email and site, taken it reached you via notification address in account.

Nevertheless, my apologies on behalf of our team. We will take your criticism to improve. None of us were born doing this and we are learning as we go.


You can get your own domain name (ie: [email protected]) so that you avoid vendor lock-in and migrate your email account to other service providers.


Get a domain, set MX records to a provider and back them up.

Worst case, you point MX to a new platform or server you own and restore from your backup.


Hello, I was planning to move to Protonmail (free version). Can you explain more about trying to lock users in?


Smart man: avoid tail-risk. Google is a tail-risk!




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: