TechPulseTechPulse
Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

56% Positive

Analyzed from 778 words in the discussion.

Trending Topics

#email#mail#key#protocols#https#mailbox#spam#idea#requests#message

Discussion (19 Comments)Read Original on HackerNews

aboardRat4•11 minutes ago
Self-ejecting panels on three sides of the website are a horrible user experience.

Other than that...

The most important thing is not the protocol, it's the gui.

At the moment email's gui is horrible on all platforms without exception.

If/when a decent gui appears, protocols will follow.

Also, JMAP did reading can probably be just WebDAV?

andros•6 minutes ago
Why do you find the panel experience so bad?
8organicbits•about 2 hours ago
I think the network effects make email hard to replace, virtually everyone online has an email address. If this could include a migration path, with backwards compatibility with SMTP, I think it would have a better shot of getting adoption.

Modern email already depends on HTTP, with protocols like MTA-STS (https://www.rfc-editor.org/info/rfc8461/) using HTTPS/TLS to improve transit encryption, or Web Key Directory (https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...) which uses HTTP for public key distribution. Personally I think these incremental improvements of SMTP are more promising than replacements, but we deserve better email however we can build it.

ccamrobertson•about 1 hour ago
I think a lot of these concepts are fun/interesting, but I like that email today functions more like a mailbox than WhatsApp or Telegram. Whilst digital (or paper) spam is obnoxious I dislike the idea of binning every sender into a "unread" box until I approve them. I miss unreads all the time across apps like X and Telegram.

As a first step I would focus on something like broad S/MIME support. Unfortunately I suspect that the biggest email providers are disincentivized from doing this as it would disrupt their business models.

thesuitonym•23 minutes ago
> Let's design the successor to email on top of HTTP

You can stop there, I've heard enough. Not everything is hypertext.

andros•19 minutes ago
Usually, informed people only read the headline.
amelius•about 3 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)?

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

Deltachat

MrGilbert•about 2 hours ago
> 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•24 minutes ago
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•17 minutes ago
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.

fny•about 3 hours ago
Is there any reason they shouldn't be the same?
xd1936•about 3 hours ago
This is the way hey.com operates. It's nice.
AKSF_Ackermann•about 1 hour ago
Content-addressed email breaks mailing lists, as those need to be able to add headers for subscribe/unsubscribe/list id, etc. There is a reason DKIM allows you to pick which headers to sign.
wuschel•about 2 hours ago
> Optional postage for strangers: the server can answer a first contact with a 402. Configurable per mailbox; the cost of cold spamming stops being zero.

Interesting take re putting a cost on spam. Perhaps another take would be functionally implementing introductions.

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

Unfortunately, this will only move the problem, and only reduce it in the case when all outside communication is ignored.

syhol•about 3 hours ago
I'm very excited by this idea. I feel like email/chat is ripe for reinvention.

I don't agree with "Domain control as a fallback", as the author said "a domain is not owned, it is rented" and I want to normalise the idea that if you lose your private key, you need to start again. I hate that we keep giving so much authority to domains, it's such a big weakness. The author even left the key rotation chain out of the initial implementation.

I still think root/signer keys or sigchains are decent options.

endre•about 1 hour ago
still better than CoI
gostsamo•about 1 hour ago
Unfortunately, stopped reading at one moment, because though the idea might be interesting, the packaging was unbearable. The obnoxious real time visitors counter seriously screws with my screen reader. I don't care how many people are reading this every 3 seconds updated not only with numbers, but with randomly chosen emois in my speech stream.

If you have a website, please, don't subject your visitors to something like that.

andros•about 1 hour ago
I'm sorry to hear about your bad experience. I've hidden the counter for screen readers. Please try again when you're ready.