Show HN: Kanmail – An email client that functions like a kanban board

But if the cores of different applications are interchangeable anyway (which they need to be, to make this model work), then why would multiple cores exist in the first place? It could just be reduced to a single one, and there'd be little incentive to start a new one if you can't deviate from the API anyway.

The closest real-world model to what you're describing, is an "implement once" public commons model; a shared commons of open-source / public domain libraries that implement a given responsibility or solution for a given problem, and that can then be used forever by everything, and that problem never needs solving again.

For that to work, the implementations in question need to be highly granular, so that using them is a no-brainer and you don't pull in additional complexity that you don't need. An "e-mail client", for example, would then effectively just be a UI, and all the business logic would be provided externally by a collection of loosely-coupled libraries.

Such a granular ecosystem, in turn, requires a dependency model where adding a dependency is (in and of itself) free and cannot cause dependency conflicts; otherwise people would start grouping complexity together again to reduce conflicts, as can be seen in the dependency ecosystems of many languages today.

The only ecosystem that is currently at a point where it can support the "implement once" model, is that of JS, due to everything being highly modular and interoperable. Rust is also moving in that direction, but its ecosystem is nowhere near mature enough yet.

Unfortunately, people are too busy complaining about meaningless dependency counts to understand what a highly-granular dependency model makes possible.

Of course, the trade-offs of "sharecropping" on someone else's platform are always there, from a strategic point of view. MS can wake up one day and rewrite Outlook in Rust, forcing you to rewrite from scratch or making it impossible in practice. But it's a possibility much more remote, imho, than the chance of making significant money with yet another exotic mail client.

Btw, we kinda had something like that: Lotus Notes and MS Exchange, originally, were abstract document stores. In theory, anyone could have built custom views that behaved as you wished, while the platform took care of email fetching and synchronizing. Unfortunately, both Lotus (later IBM) and Microsoft saw those platforms as lock-in instruments in a push for vertical dominance, so they had no incentive but to push their own clients.

In Prefereneces -> Sidebar set slack to only show "Unreads and starred conversations". This reduces the list of channels to these two things. (Edit: it might be a good idea to star all conversations that need followup, first).

Muted channels (which I make use of a lot) will still not trigger notifications, but now you'll know that, if it appears in the sidebar, there are unreads there.

I star any conversations that comes up and needs followups or actions. When I'm done with it, I unstar it and it goes away.

This has worked wonders for me and I highly suggest the same workflow to everyone.

Note that after the latest Slack update, it should be possible to make use of the groups feature and use them together with the workflow above. This way you can have multiple statuses like TODO, awaiting reply and delegated, like in the parent article, rather than a single set of starred conversations. So far I haven't felt the need for this personally.

Oh and one more thing. In Preferences -> messages and media set it to "Compact", it will declutter the UI a bit.