In a closed community with highly sensitive content, everyone wants guaranteed zero emails starting from registration. Is this possible in Discourse?
I guess we can turn emails off entirely system wide, but what about new user registrations? Now that you even support passkeys, could you make a fully functional no-emails Discourse possible?
I think you should be able to do this, if you have SSO setup.
Emails are an absolutely requirement to verify email addresses. Otherwise you’ll get hit by spam. But you can bypass this if you delegate verification to your SSO set this:
I’m on a site with email disabled, and I think that is only possible because of the SSO handling login and password resets, etc.
Without needing those, I think using onsite notifications and having no email notifications for anything works quite well. 
Hey, I’ll be the devil advocate for a while. It’s not my usual interaction around here because I truly respect all of you folks.
But I guess that being the crypto guy (people say OG) and after giving a decade learning to self-host my files, nodes, websites and blablah, motivates me to share my thoughs to you.
I have 7 years supporting Discourse and I manage a community that value privacy.
They trust on me (someone can say I’m not the guy but they know that I’m their guy) and they learn how to keep their own privacy at first.
Discourse is not built with stronger privacy on mind, it’s about mostly public communities.
Primarly tech support regardless the software itself is used for different markets, concepts, nations and so on 
Depreceated encrypt PMs shows the reality: only 1% on the world takes care about their privacy.
Meta on Discourse is not different and I bet your own community neither (remember a lot of guys trusting on a random on internet like me, so we are all the same).
Apple, Amazon, Microsoft, Facebook, Google make money killing their users privacy. And almost everyone depends everyday on them.
Are you browsing on Chrome? You have no privacy.
1. Extensive Data Collection and Profiling
2. Third-Party Cookies and Privacy Sandbox Controversy
3. Browsing History Leaks via :visited Links
:visited CSS selector, which could be exploited for tracking, profiling, and phishing. This longstanding vulnerability was only addressed in Chrome version 136 with a new partitioning system to prevent cross-site history leaks3.4. Personalized Ads Based on Browsing History
5. Lawsuits and Regulatory Scrutiny
6. Integration with Google’s Wider Ecosystem
| Issue | Description | Source |
|---|---|---|
| Data Collection & Profiling | Chrome collects and links vast amounts of personal data for profiling and ads | 427 |
| Third-Party Cookie Phase-Out Failure | Google’s delays and reversal on cookie removal leaves users exposed to tracking | 85 |
| Browsing History Leak via :visited Links | Exploitable CSS feature leaked browsing history for decades; only recently fixed | 3 |
| Personalized Ads from Browsing History | Chrome uses recent browsing activity for ad targeting, raising transparency and consent issues | 2 |
| Lawsuits & Regulatory Action | Legal challenges over alleged unlawful data collection, including in private browsing modes | 7 |
| Google Ecosystem Data Integration | Chrome data combined with other Google services for extensive profiling | 4 |
These issues have contributed to ongoing debates about Chrome’s suitability for privacy-conscious users and have prompted some to recommend alternative browsers with stronger privacy protections47.
So, back in topic, going on SSO route for real privacy means to self-host the service on local hardware or encrypted HD/SO.
I think Authentik -tested with Discourse- is our best bet for those who want open-source, community, respect and common sense.
I like to suggest e-mail alias services like Duck or Addy (better to self-host, from my perspective).
And move to LibreWolf ASAP.
Best wishes for your community and project. It’s good to see discussions about the major vortex on Internet.
I was very disappointed when Discourse stopped supporting encrypted messaging. We were using it like a lot.
Thanks for the hint.
When considering setting up an email-less Discourse instance, there is no way to get hit by spam.
When I say “email-less”, I really mean that in the absolute meaning. It’s not that difficult, most of it already exists in Discourse: you can just turn off sending out any emails completely. The only two missing bits are:
I advocate for a single global switch such as “Email-less Discourse”, which will disable email and make it unnecessary throughout the application.
If the user installs the Discourse app, he’ll get all the updates through it, no need for an email.
If ther user uses a keypass, no need for an email either.
If no digest emails are sent, no need to verify emails.
Frantly, no need to have any email associated with an account at all.
I may sound a bit overwhelming, but in the same time, it is a) not that difficult to complete the remaining/missing 5% that hard-require email, and b) in my practice, it’s a legit case to have a email-less community, and it’s not very unique of an idea - in multiple web shops you can already “buy anonymously”, i.e. you can interact with the platform and even place an order without ever revealing your email. 4chat is yet another example that requires no user email but is huge.
I guess all that’s missing is the will of the Discourse team to embrace the idea and complete a few tweaks to make Discourse truly email-less capable. It’s almost there already.
you can skip this as well with a command line during setup, I can’t remember off top of head
You email initially for setup However. We had a test site running with no email server after. Invite link may work for signup. We didn’t test invite link but manually activated accounts.
This pluginay help. But would verify in this post that it is still current. Looks like fork was released in March