Remix.run Logo
amelius 4 hours ago

> 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)?

TheOtherHobbes an hour ago | parent | next [-]

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.

tcfhgj 19 minutes ago | parent [-]

> You do get it on chat services, but there's no option there to create sub-conversations.

It's called threads - even Matrix has these

aboardRat4 an hour ago | parent | prev | next [-]

>Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?

Deltachat

MrGilbert 3 hours ago | parent | prev | next [-]

> 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?

thesuitonym 2 hours ago | parent [-]

Believe it or don't, most mailservers actually are set up this way, but it's completely invisible to the user: https://en.wikipedia.org/wiki/Greylisting_(email)

Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.

dizhn an hour ago | parent [-]

It is similar but not the same thing. It does not have anything to do with the email being legit (non spam) or not. It only catches emails that do not do what they supposed to do when they are deferred for a little bit. They are supposed to try again later. (A super nice feature of email which protects you from losing all incoming emails when your server is down for a short time). The reasoning here is hopefully a spam script or software will not implement the standard properly or will skip apparently broken destinations.

What parent wants is also possible and I remember people doing it as far back as the early 2000s. You would basically manually whitelist an email or have them bypass the list (once or always) with something like a key word or token sort of like a captcha which can be shared off band.

thesuitonym an hour ago | parent [-]

It's definitely possible, a few companies do it, and let me tell you: People hate it.

fny 4 hours ago | parent | prev | next [-]

Is there any reason they shouldn't be the same?

xd1936 4 hours ago | parent | prev [-]

This is the way hey.com operates. It's nice.