Imagine an architecture where incoming emails are parsed to extract key metadata such as sender, subject, category, priority, and body content and then published to a local Kafka queue. From there, applications can subscribe to specific topics or filters, just like they do with notifications or system events.
Think of the possibilities:
- A CRM system could subscribe to emails from clients and auto-log interactions.
- A task manager could subscribe to emails tagged as “Action Required.”
- A personal assistant app could subscribe to calendar invites or travel confirmations.
Users could manage these subscriptions through a simple UI, similar to notification preferences. This model treats email as a stream of structured events, enabling real-time automation, integration, and personalization.
Where things get interesting is what you could do with streaming from multiple sources: not just email, but Slack, Teams, social media accounts - all the different ways you connect with people.
Rethinking email is great, but IMHO you are not taking full advantage of the opportunities that arise from building a new client. When you build a new client, you can not only process incoming emails in new ways, but you can also change the way outgoing emails are handled. You can build a new protocol on top of SMTP that will solve many of the extant problems with email, including authentication and spam. You don't have to put up with the current standards and their historical baggage. You can build a new one.
For example: one of the biggest problems with email is that SMTP is not stateful. It handles all incoming messages in the same way. In particular, SMTP does not and cannot distinguish between spam. Spam detection is invariably relegated to a downstream heuristic system that generally looks at message content to detect spam. But this cannot possibly be reliable because one man's spam is another man's newsletter subscription.
What if instead we moved spam detection into the protocol. What if (say) we replaced the single-step process of sending an email into a two-step process, where the first step involves some kind of hand-shake to establish a connection between the sender and the receiver. This simple change would make it literally impossible to send any kind of spam other than a connection request. Those would still happen, of course (think LinkedIn "I want to connect" messages) but they would be a lot less frequent. And there are ways to eliminate even those annoyances.
A new client could become to email what iMessage is to SMS. You could have "blue bubble" messages that are authenticated as having come from the same client, which insures that the user has gone through some some level of vetting (comparable to an iPhone user signing in to their iCloud account). You could even layer new protocols on top of SMTP that were unique to your client's ecosystem, like sending money.
This idea is conceptually simple but very hard to implement because it has to be done in the client and it has to be backwards-compatible with SMTP. But since you're building a new client anyway, I thought I'd pitch this idea to you. The result could potentially be an entirely new email ecosystem.
If you want to discuss this in more detail, contact me privately. My contact info is in my profile.
Why not treat email as a dynamic event source?
Imagine an architecture where incoming emails are parsed to extract key metadata such as sender, subject, category, priority, and body content and then published to a local Kafka queue. From there, applications can subscribe to specific topics or filters, just like they do with notifications or system events.
Think of the possibilities:
- A CRM system could subscribe to emails from clients and auto-log interactions.
- A task manager could subscribe to emails tagged as “Action Required.”
- A personal assistant app could subscribe to calendar invites or travel confirmations.
Users could manage these subscriptions through a simple UI, similar to notification preferences. This model treats email as a stream of structured events, enabling real-time automation, integration, and personalization.
Where things get interesting is what you could do with streaming from multiple sources: not just email, but Slack, Teams, social media accounts - all the different ways you connect with people.
This didn't get much traction last week: https://news.ycombinator.com/item?id=45272456
Rethinking email is great, but IMHO you are not taking full advantage of the opportunities that arise from building a new client. When you build a new client, you can not only process incoming emails in new ways, but you can also change the way outgoing emails are handled. You can build a new protocol on top of SMTP that will solve many of the extant problems with email, including authentication and spam. You don't have to put up with the current standards and their historical baggage. You can build a new one.
For example: one of the biggest problems with email is that SMTP is not stateful. It handles all incoming messages in the same way. In particular, SMTP does not and cannot distinguish between spam. Spam detection is invariably relegated to a downstream heuristic system that generally looks at message content to detect spam. But this cannot possibly be reliable because one man's spam is another man's newsletter subscription.
What if instead we moved spam detection into the protocol. What if (say) we replaced the single-step process of sending an email into a two-step process, where the first step involves some kind of hand-shake to establish a connection between the sender and the receiver. This simple change would make it literally impossible to send any kind of spam other than a connection request. Those would still happen, of course (think LinkedIn "I want to connect" messages) but they would be a lot less frequent. And there are ways to eliminate even those annoyances.
A new client could become to email what iMessage is to SMS. You could have "blue bubble" messages that are authenticated as having come from the same client, which insures that the user has gone through some some level of vetting (comparable to an iPhone user signing in to their iCloud account). You could even layer new protocols on top of SMTP that were unique to your client's ecosystem, like sending money.
This idea is conceptually simple but very hard to implement because it has to be done in the client and it has to be backwards-compatible with SMTP. But since you're building a new client anyway, I thought I'd pitch this idea to you. The result could potentially be an entirely new email ecosystem.
If you want to discuss this in more detail, contact me privately. My contact info is in my profile.
You're welcome :-)
This doesn’t do a good job of saying what is going to be different or what it’s going to be like. It’s simply, “AI magic”.