privacy.fish

— ultra-minimal privacy focused email from Norway.
€20 one-time payment for a lifetime account.

Data minimization done right.

[privacy.fish @privacyfish]

@emilson_tery Exactly. “Encrypted to our cloud” and “stays on your device unless you choose otherwise” are different threat models. Data location and retention should be upfront, not buried in a policy.

[privacy.fish @privacyfish]

@kuriharan This framing matters: the privacy problem is not only data collection, but data turned into individualized leverage.

A useful rule of thumb is that if a service can work without profiling the person, the profile should not exist by default.

[privacy.fish @privacyfish]

@keepontruckin78 One idea: make AI strictly opt-in per mailbox, with clear retention boundaries and a non-AI path that is just as usable.

For mental-health workflows, the privacy win is not only encryption at rest; it is minimizing what gets logged, indexed, summarized, or retained by default.

[privacy.fish @privacyfish]

@siyaaaamak If a product can work with less retained data, narrower logs, local processing, or clearer deletion boundaries, that is stronger than asking users to trust future restraint.

[privacy.fish @privacyfish]

@MyStartMail A warrant rule helps with government access, but email privacy also depends on provider defaults: retention, access logs, recovery data, payment/account links, webmail exposure, and how much metadata is kept at all.

[privacy.fish @privacyfish]

This is a good way to frame it. The “slow migration” point matters because email is tied into everything: banking, legal docs, account recovery, family logistics, work history.

[privacy.fish @privacyfish]

@jpdemas Good place to be deliberate. Local-first email usually lives or dies around sync boundaries: what is cached, how conflicts resolve, token isolation, and how much provider metadata remains searchable. The boring data model choices become the privacy model later.

[privacy.fish @privacyfish]

@adityadotdev Good list. One thing I’d add under email: the provider choice is only part of it.

Also look at recovery, metadata retention, remote image loading, client access, and whether the inbox becomes another cloud profile.

[privacy.fish @privacyfish]

@jacobthomsencom One great way to do email privacy: restrict the mail client with a firewall, e.g. Qubes. If it can only talk to SMTP + imap.mailserver.tld, tracking pixels can’t phone home. Rendering email as plain text instead of HTML helps a lot too.

Love what you’re building. Keep it up!

[privacy.fish @privacyfish]

@jacobthomsencom We chose a one-time-payment to keep the bar for cash-by-mail extremely low, because it is the most privacy friendly payment option. This way you never have to tell us your real name. It costs us profit, but it protects your privacy.
Business model: Your privacy above everything.

[privacy.fish @privacyfish]

@jacobthomsencom Recurring payments create issues for your privacy - we want to make the bar very low for people to just paper-mail us the 20 Euros. It costs us profit, but its better for your privacy.
Our business model is to protect your privacy at all cost - even at the expense of profit ;-)

[privacy.fish @privacyfish]

@jacobthomsencom A calmer inbox is partly UI, but partly fewer invisible things happening when you just read a message.

[privacy.fish @privacyfish]

@jacobthomsencom Calmer email is an underrated privacy angle. A lot of inbox privacy discussions jump straight to encryption, but control over tracking, sender trust, and what gets promoted into the main inbox matters too.Curious how you’re thinking about local processing vs server-side filtering

[privacy.fish @privacyfish]

One practical email privacy question:

if police, an attacker, or a lawyer asks the provider for mailbox data, what can the provider actually hand over?

For us, the answer starts with collecting less — including how signup and payment work.

https://t.co/X95soXatRc

[privacy.fish @privacyfish]

@Berson_lott Agree on not asking people to migrate; that’s where most email products die. The trust question is the permission boundary: what gets read, what gets retained, and how easy it is to make the assistant forget context. If it sits above Gmail/Slack/Notion, control has to be obvious.

[privacy.fish @privacyfish]

@vivaldibrowser Nice list. For the email slot, one more European option: https://t.co/y2iZ2l72Yg — Norwegian private email for technical users: SSH-key login, local-first mail storage, no webmail/analytics, and intentionally fewer convenience features. Disclosure: this is our account.

[privacy.fish @privacyfish]

@yourfeedofme That’s the real concern. I’d draw the line at “prove only the minimum fact, once, without reuse”: no biometric registry, no cross-site ID token, no retained verification logs, and no VPN/Tor block. If it can follow you across sites, it isn’t just age verification anymore.

[privacy.fish @privacyfish]

@RealTankTheta @AyakaMods For creator archives, I’d treat cloud as sync/convenience, not the only copy: local master folder, one offline drive, and one encrypted offsite copy. Cryptomator/rclone/restic are worth a look. Key rule: no single account should be able to delete your work.

[privacy.fish @privacyfish]

@AntiBamse @davidgpeterson @joinduelcom @ProtonVPN Disclosure: we’re building https://t.co/JG9CVIrH6Z, so biased. Email “no logs” is tricky: SMTP needs auth/abuse/deliverability records. Our Norway writeup covers the narrower baseline we chose: access time, username, source IP/port; no destination log. https://t.co/MHW49M2zmF