Live data from Hacker News

Modern email can be built from borrowed parts

en.andros.dev

111–120 of 165 posts

Re: Modern email can be built from borrowed parts

#111
post #91

The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think. It reminds me of a previous life, at a previous time, when everybody reinvented the content management system based on slightly different approaches, because they thought existing CMSs were too big. It starts with serving pages, then you want multipl…

I've been using email since the 1980s.

I've ... seen a lot of poorly-considered proposals to fix it.

The fact that email has one hell of a lot of lock-in does not mean that it's not-broken. Just that it happens to be in one hell of a local optimum from which reaching any preferable state has a lot of hill-climbing to do.

Much in the way that evolution is not teleological, and cannot identify some desired state it wishes to evolve toward, but must proceed, by stepwise incremental increases in fitness to another state, so it is with protocols and standards.

That's not to say that SMTP + fiddly bits doesn't solve some problems, occasionally elegantly. But the leap from there to "it's not as broken" is ... rather large.

I've read TFA and am going through comments to this thread. There are some ideas I like, some I question. I'd suggest that this proposal seems better though through than many others I've seen.

Re: Modern email can be built from borrowed parts

#112
post #51

Earlier quoted context omitted.

It's very annoying on mobile, covering half of the page all the time

When you scroll down, they should all disappear. Do you have JavaScript disabled? What browser and device are you using?

The panels keep pushing back into the screen on Mobile.

I quickly resorted to Reader View (Firefox/Android).

Remove those, or stuff them below the article.

Re: Modern email can be built from borrowed parts

#113
post #71

A better protocol for email seems like it should be lower on the list compared to a better protocol for phone calls. And don't just say we'll build that on HTTP too!

I'm thinking through the latter presently: https://mastodon.social/@dredmorbius@toot.cat/11698405157843...>.

And I see a few ideas that might be worth picking up from this proposal.

Voice and text comms ... have much in common.

Re: Modern email can be built from borrowed parts

#114
post #51

Earlier quoted context omitted.

When you scroll down, they should all disappear. Do you have JavaScript disabled? What browser and device are you using?

The panels keep pushing back into the screen on Mobile. I quickly resorted to Reader View (Firefox/Android). Remove those, or stuff them below the article.

The mobile interaction is similar; it's not a bug, it's by design. If you were able to read the article without any problems, I'm satisfied. Thanks for the feedback.

Re: Modern email can be built from borrowed parts

#115
post #105

Earlier quoted context omitted.

Yes, but when I stop scrolling and scroll up even a little bit (by accident, or because I want to scroll up and read something I missed) they appear again. I think the only good UX possible is to have a button to show/hide them instead.

I'm sorry, but I disagree. The lowest interaction cost is scrolling; it's a natural, continuous, and almost involuntary gesture. Having to click or tap a button requires the user to stop, evaluate whether the title interests them, and decide to make the effort to tap. The interactions you're describing are intentional and measured. I'm sorry but if the content is truly all you care about, I recommend the previous opt…

> almost involuntary gesture

Exactly, which is why attaching large UI shifts to that involuntary gesture makes the experience feel very unpredictable

> activating your browser's reading mode

Reading mode is a hack that's only needed because sites aren't already readable. You shouldn't have to activate it to be able to read the content.

In addition, it doesn't always work well if the website didn't test it. On your website, for example, it removes all images from the text.

> Having to click or tap a button requires the user to stop, evaluate whether the title interests them

Purposefully doing things in a way that doesn't let the user decide if they want it is called a dark pattern. Its not far from those checkboxes that try to trick you into accepting marketing newsletters. "We can't give users an option to think if they want our emails! If they don't, why don't they just use their email's spam filtering?"

You may not see it like that yourself, but huge links to your CV, talks and courses are exactly that - an ad that covers half the screen.

You have multiple people telling you the experience is bad, and you asked for why, but when people give you the explanation you argue back. That's fine of course, it's your own site and you can do whatever you like with it without trying to suit anyone. But that doesn't make the reader experience less bad.

Re: Modern email can be built from borrowed parts

#116

Earlier quoted context omitted.

>> The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think. email is one of those technologies that "just works" but so many people seem to think it needs to be "fixed". it's generally very reliable and so people should just accept that and be grateful. It could be worse - it could be enshittified like so…

> it's generally very reliable and so people should just accept that and be grateful It's only really "very reliable" if you use Google or Microsoft for email, since they are the arbitrator of modern email.

I admit it’s sometimes painful to self-host your SMTP service, but that’s because it was very painless to send massive amounts of spam and very painful to throttle and filter messages, but we have much better tooling now.

Re: Modern email can be built from borrowed parts

#117

Here is another, not so new, idea: Username is your public key, password is your private key. So we get end to end encryption and account ownership out of the box. Something similar to how .onion addresses work. Needing easy to remember addresses? Build aliases on top of that. Needing server-side automation? Handle trusted server your private key. Also, almost everyone carry a 24/7 powered and Internet connected devi…

Tightly coupling identity to cryptosystems should be entirely dismissed for anything that is supposed to have broad adoption.

First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system.

Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not.

Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity.

In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).

Re: Modern email can be built from borrowed parts

#118

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…

The FOSS MTAs generally don't implement any of the HTTP features… because they require HTTP.
Post reply on HN