alt Hacker News> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room.
I like this.
Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?
Replies
I (and many others) do this:
https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...
(Not answering your question, but referring to the approach).
>Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?
Deltachat
> I like this.
Honestly, I'd want this as a default. I wonder if a mailserver can be configure like this. Doesn't sound too hard, does it?
other email clients/services like Hey etc do this.
at one point Gmail had a service for this - if I remember well - but google being google - I guess it was just a promotion project for someone.
Is there any reason they shouldn't be the same?
This is the way hey.com operates. It's nice.
The unknown request will be buried in spam - a problem we have already, but worse.
And I do not want an infinite thread conversation. I want to be able to split off - and perhaps archive and export - different conversations by topic.
I recently had to some legal things, which included forwarding copies of a certain conversation to a lawyer. This turns out to be unreasonably difficult because email clients quote previous conversations. You want a clean thread of comment and reply about a specific topic. You don't get that.
You do get it on chat services, but there's no option there to create sub-conversations.
If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. Protocols are far downstream of that.