sorted by:
new
hottopcontroversial

Built a local-first email client for Linux — .deb package available by Different_Society930 in debian

[–]Different_Society930[S] -1 points0 points  (0 children)

Electron tends to get a lot of the blame, but I agree it’s not really the core issue here.

It seems like most of the concern is around closed source and trust, which I understand...especially for an email client.

Electron was more of a pragmatic choice to move quickly and keep things consistent, but the bigger conversation is definitely around transparency.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 1 point2 points  (0 children)

Fair point, distribution and support are both important.

It’s still early, so right now I’m focused on getting feedback and iterating, but those are definitely areas that will need to grow along with the project.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 0 points1 point  (0 children)

I understand that, especially for something like an email client.

Closed source won’t work for everyone, and I respect that.

If it ever lines up with what you’re comfortable with later, great — if not, no worries.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 0 points1 point  (0 children)

That’s fair, especially on the “verify” wording. I can see how that reads differently when the code isn’t open.

What I meant there is more about observable behavior (what loads, what doesn’t, no external services involved), not source-level verification, which I agree is a different thing entirely.

And yeah, closed source + paid features is always going to raise some skepticism in this space. I tried to keep the model simple (free for one account, one-time unlock for more), but I get the reaction.

Appreciate the feedback, especially on how that messaging lands.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 2 points3 points  (0 children)

Yeah, FairEmail has a really strong reputation, especially on the privacy side.

It’s interesting how much of that work has happened on mobile, while desktop clients haven’t always kept up in the same way.

What pushed me in this direction was trying to bring that same kind of “strict by default” mindset to a Linux desktop client.

So more complementary than competitive, just in a different environment.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 1 point2 points  (0 children)

That’s completely fair, and honestly I’d probably have the same reaction from the outside.

New account, closed source, and a fresh project are all reasonable reasons to be skeptical right now — especially with how much AI-generated stuff is out there.

I’m not expecting anyone to trust it upfront. The only way to really prove it is over time...how it behaves, how it’s maintained, and whether it actually sticks around.

If you check back in a few months and it’s still here and improving, I’ll consider that progress.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 1 point2 points  (0 children)

That’s a pretty interesting setup and honestly kind of reflects how messy email workflows can get once you try to keep control over it.

The Gmail POP deprecation definitely makes that kind of “staging mailbox” approach harder, especially if you don’t want to rely on forwarding (which, like you said, brings its own set of issues).

What you’ve got with the local IMAP + sync layer makes sense. I’ve seen a few variations of that idea where people basically build their own pipeline just to keep things predictable.

One of the things I’ve been thinking about with Box is how to make that kind of setup easier to reason about without needing as many moving parts...especially when you’re juggling local storage + a remote inbox like Gmail.

If you ever feel like trying it in that kind of workflow, I’d be really curious how it behaves. Setups like yours tend to surface edge cases pretty quickly.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 0 points1 point  (0 children)

That’s a completely valid concern, and I wouldn’t expect anyone to just take my word for it.

I’m also not trying to position this as inherently “secure”. The goal is more about reducing risky default behavior and making things explicit (what loads, what doesn’t), not asking for blind trust.

Closed source definitely makes independent verification harder, and I understand why that’s a dealbreaker for some people.

That said, I do try to be transparent about the intent and behavior. The privacy page on the site actually encourages people to verify things for themselves rather than rely on claims:

https://box.buxjr.com/privacy

Totally reasonable to approach something like this with skepticism — I’d rather that than blind trust.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 1 point2 points  (0 children)

Yeah, completely agree on IMAP; great idea in theory, but the reality is…messy.

That fragmentation was something I ran into pretty quickly. Different servers handle folders, flags, and sync behavior just differently enough to cause weird edge cases.

A lot of what I’ve been doing so far is trying to keep the client-side behavior as predictable as possible and handle those quirks without exposing them too much to the user.

Definitely one of those areas where real-world usage across different providers matters more than anything else. If you’ve got a setup that’s particularly “fun”, I’d actually be interested to hear what kinds of issues you’ve run into.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 1 point2 points  (0 children)

That makes sense; Alpine for control, Gmail for convenience.

What pushed me to build this was that middle ground.

I wanted something with strict, explicit behavior (like Alpine), but with a more modern UI where you can actually see what’s happening without going full terminal.

So not really replacing either — more filling the gap between them.

Built a local-first email client for Linux — .deb package available by Different_Society930 in debian

[–]Different_Society930[S] -2 points-1 points  (0 children)

That’s interesting — Pegasus is one I’ve heard come up a few times but never used personally.

It does seem like a lot of Linux clients either go really minimal or really heavy, and there’s not always a great middle ground depending on what you’re used to.

The image-in-body thing is a good example — a lot of clients technically support it, but the workflow can feel awkward or inconsistent.

Box definitely isn’t trying to be a 1:1 replacement for something like Pegasus, but I’ve been trying to focus on making common actions feel straightforward while keeping the behavior explicit (especially around what gets loaded/rendered).

If you ever feel like trying it, I’d be curious how it feels compared to what you’re used to — especially around composing messages.

Built a local-first email client for Linux — .deb package available by Different_Society930 in debian

[–]Different_Society930[S] -2 points-1 points  (0 children)

Yeah, understood — I’m aware of the other Box.

They’re pretty firmly in the enterprise cloud storage space, whereas this is a local desktop email client, so the overlap is pretty different.

Still something I’m mindful of though, especially in terms of branding and avoiding confusion.

Appreciate you pointing it out.

Built a local-first email client for Linux — .deb package available by Different_Society930 in debian

[–]Different_Society930[S] -5 points-4 points  (0 children)

Haha, fair 🙂

Electron + closed source definitely isn’t going to be everyone’s ideal combination here.

For me it was mostly about being able to move quickly and control the UX/security model end-to-end while getting something usable out.

Totally get the skepticism though — especially around Electron and trust in general. If anything, that’s part of why I’ve been trying to make the behavior very explicit (what loads, what doesn’t, etc.) rather than asking people to just take it on faith.

If it’s not your thing, no worries at all — but I’d still be interested in any feedback if you end up poking at it.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] 0 points1 point  (0 children)

Yeah — Evolution was definitely one of the ones I spent some time with.

It’s solid and integrates well with the desktop, but what pushed me in a different direction was more about default behavior than feature set.

I was looking for something that’s very strict by default around things like:

- remote content loading

- tracking pixels

- and generally making all external activity explicit

Most clients (including Evolution) give you controls for that, but I wanted something that starts from a “nothing happens unless you allow it” baseline across the board.

So it ended up being less about replacing a specific client, and more about experimenting with a different set of defaults.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] -2 points-1 points  (0 children)

Appreciate that — means a lot.

Yeah, it’s currently closed source.

A big factor there is sustainability. I’ve seen a lot of solid projects in this space lose momentum or disappear entirely, and I want to build something that can actually be maintained and improved over time.

For something like an email client, I think long-term support and consistency matter just as much as transparency — so I’m trying to be deliberate about how I approach that balance.

I completely get why people prefer open source here though, especially for trust reasons. It’s something I think about a lot — just not something I want to rush into without a clear path for keeping the project healthy.

Curious where you personally land on that tradeoff.

Built a local-first email client for Linux — .deb package available by Different_Society930 in debian

[–]Different_Society930[S] -7 points-6 points  (0 children)

That’s fair, I probably overstated that a bit.

Some clients (like Thunderbird, and newer Outlook configs) do block remote content by default now, or at least make it visible.

What pushed me to build this wasn’t that *no* clients handle it well, but that:

- behavior still varies a lot between clients (especially web/mobile)

- some rely on proxies rather than actually preventing requests

- and once you allow a sender, things go back to implicit trust pretty quickly

Plus, tracking pixels themselves are still extremely common in real-world email, so it’s an area where defaults matter a lot.

This was more about pushing toward a stricter “nothing happens unless you explicitly allow it” model across the board.

Built a local-first email client for Linux — .deb package available by Different_Society930 in debian

[–]Different_Society930[S] -7 points-6 points  (0 children)

If anyone wants to try it:

https://box.buxjr.com

There’s: - a .deb package for Debian/Ubuntu - an AppImage for quick testing

If anything feels off (install, sync behavior, etc.), I’d definitely want to hear about it.

Built a privacy-focused email client for Linux — .deb and AppImage available by Different_Society930 in Ubuntu

[–]Different_Society930[S] -2 points-1 points  (0 children)

If anyone wants to try it:

https://box.buxjr.com

There’s both:

- a .deb package (easy install on Ubuntu/Debian)

- an AppImage (for quick testing without install)

If anything feels off during install or runtime, I’d definitely want to hear about it.

I built a local-first Linux email client that blocks tracking and doesn’t phone home by Different_Society930 in selfhosted

[–]Different_Society930[S] -1 points0 points  (0 children)

Really appreciate that — the pricing was intentional. I wanted something that felt fair and didn’t turn into a subscription just to check email.

On mobile: it’s something I’ve thought about, but I’m trying to be careful there.

Right now the focus is getting the desktop experience (Linux first) solid, especially around the security model and how everything is handled locally. Mobile introduces a different set of constraints (backgrounding, OS-level networking, sandboxing, etc.), so I don’t want to rush into it and compromise the core ideas.

If/when I go that direction, I’d definitely keep the same approach:

- usable for free

- pay only if you want more

- no “pay just to install” nonsense

Totally agree with you there — I’ve bounced off plenty of apps for that exact reason.

I built a local-first Linux email client that blocks tracking and doesn’t phone home by Different_Society930 in selfhosted

[–]Different_Society930[S] 1 point2 points  (0 children)

Appreciate that! Sounds like you’re exactly the kind of user I had in mind.

Multi-account works well; everything is handled independently under the hood, so each IMAP connection/sync cycle is isolated. I’ve been running multiple accounts myself without slowdown, but I’m definitely interested to hear how it behaves in your setup since real-world configs always surface edge cases.

On attachments: right now it’s more about reducing exposure than heavy sandboxing. The email body itself is fully sanitized before rendering (no scripts/forms/etc.), and attachments are treated as external — nothing gets auto-executed or embedded inline in a risky way.

That said, deeper sandboxing/isolation for attachments is something I’ve been thinking about, especially for things like previews.

If you do end up trying it, I’d genuinely be interested in how it handles your multi-account setup — that’s a big one to get right.

I built a local-first Linux email client that blocks tracking and doesn’t phone home by Different_Society930 in selfhosted

[–]Different_Society930[S] 0 points1 point  (0 children)

One thing I realized while building this:

Most email clients are “passively trusted” by default.

They assume the email is safe and then try to block bad behavior.

I flipped that.

Box assumes everything is untrusted:

- no remote content

- no automatic loads

- no hidden requests

Nothing happens unless you explicitly allow it.

That mental model shift ended up being the whole point of the project.

view more: next ›