Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scaling email transparency

stripe.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Scaling email transparency

#11

Post by derefr »

grey-area wrote: post #6
chimeracoder wrote: post #5

Earlier quoted context omitted.

> I think everyone would love to see an email killer come along Can you explain this? I've heard this sentiment before and never really understood it. The common complaints I hear about email are usually inherent in the fact that it's a universal communication mechanism[0], or a symptom of inadequate clients[1]. I can understand the need for better email clients (that's what Gmail originally was, back in the day[2]).…

But I still haven't been able to find a compelling reason that email itself is fundamentally broken in a way that requires a new system altogether. I'd love to use something very much like email which had a few things like this: Verified identity Public key encryption as standard (of content at least, possibly of most headers too) TLS everywhere UTF-8 everywhere Metadata for social presence so that twitter/fb/github/…

> Maybe even mail uploaded to a server and not sent across the wire unless actually requested - why do we need to send messages when I might be able to infer from metadata that I don't want to read it 50% of the time?

If you go there, you're basically talking about something that's more like blogs with RSS feeds, rather than email. To me, half the point of email is that it is "pushed": this allows to send messages to people you don't already have pre-existing relationships with, simply by finding out their contact details.

Re: Scaling email transparency

#12

Post by grey-area »

derefr wrote: post #11
grey-area wrote: post #6

Earlier quoted context omitted.

But I still haven't been able to find a compelling reason that email itself is fundamentally broken in a way that requires a new system altogether. I'd love to use something very much like email which had a few things like this: Verified identity Public key encryption as standard (of content at least, possibly of most headers too) TLS everywhere UTF-8 everywhere Metadata for social presence so that twitter/fb/github/…

> Maybe even mail uploaded to a server and not sent across the wire unless actually requested - why do we need to send messages when I might be able to infer from metadata that I don't want to read it 50% of the time? If you go there, you're basically talking about something that's more like blogs with RSS feeds, rather than email. To me, half the point of email is that it is "pushed": this allows to send messages to…

You could push the fact there is a message at date n from x with subject y to the recipient servers without wasting bandwidth on the message itself along with attachments before you know it will be read. This would also have other effects (possibly delete/modify after send, invert control from the recipient to the sender etc), so it certainly would change the way email is used - probably not everyone would agree with this particular point.

Re: Scaling email transparency

#13

Post by gdb »

derefr wrote: post #10
gdb wrote: post #8

Earlier quoted context omitted.

Email transparency is one tool for spreading information within an organization. It excels at some use-cases (namely, freeing email that would normally be locked up in someone's inbox). However, it's poor at other cases: for example, it has no story for making that information more digestible (most teams address this by sending periodic state update emails to the company). Said another way, just lobbing an email to a…

> Immediately, people started to express strong opinions in favor or against it. We had a full-company sitdown to talk about it, but it was really weird because it was all just hypotheticals. Ultimately, we burned a lot of time on it, and the deal was kind of dead in the water due to this approach. This sounds like the sort of problem you solve with a policy, not by breaking the enabling technology. What about just t…

It's kinda (and in some cases maybe even irresponsible) unfair to drop major things on people without providing more context. The point of email transparency isn't to make everything transparent; it's to increase efficiency. We don't need to cover everything.

Generally with similar initiatives these days we'll talk about them at all-hands, or if they're particularly interesting have a dedicated gathering to discuss them. We also find ways of increasing transparency once the need for secrecy has been removed, such as opening up the list archives post-hoc.

Re: Scaling email transparency

#14

Post by fishnchips »

I have too much email of my own to go around and read someone else's, email transparency or not. In all fairness I think this is just creating a false sense of openness at a cost of potential severe information overload (or underfiltering).

Re: Scaling email transparency

#15

Post by gdb »

fishnchips wrote: post #14

I have too much email of my own to go around and read someone else's, email transparency or not. In all fairness I think this is just creating a false sense of openness at a cost of potential severe information overload (or underfiltering).

Don't read it then! But it can still be useful to have a lot of auto-archived email in your inbox -- for example, searching for a name or topic will often pull up relevant threads you otherwise wouldn't have been discovered.

Re: Scaling email transparency

#16

Post by fishnchips »

gdb wrote: post #15
fishnchips wrote: post #14

I have too much email of my own to go around and read someone else's, email transparency or not. In all fairness I think this is just creating a false sense of openness at a cost of potential severe information overload (or underfiltering).

Don't read it then! But it can still be useful to have a lot of auto-archived email in your inbox -- for example, searching for a name or topic will often pull up relevant threads you otherwise wouldn't have been discovered.

That's what mailing lists are for and it's hardly an innovation.

Re: Scaling email transparency

#17

Post by gdb »

fishnchips wrote: post #16
gdb wrote: post #15

Earlier quoted context omitted.

Don't read it then! But it can still be useful to have a lot of auto-archived email in your inbox -- for example, searching for a name or topic will often pull up relevant threads you otherwise wouldn't have been discovered.

That's what mailing lists are for and it's hardly an innovation.

Yep. Email transparency gracefully degrades into just a plain old mailing list.

Re: Scaling email transparency

#18

Post by eikenberry »

chimeracoder wrote: post #5
gdb wrote: post #3

Earlier quoted context omitted.

We do use Slack. It's great for real-time communication, and has made us way happier than any other chat system we've tried. (In fact, a year prior we'd tried out lots of chat systems, each time feeling like the switching cost to try was higher than whatever incremental value we were getting. But when we came across Slack, it was so obviously better we decided to try again. We ended up pretty painlessly switching wit…

> I think everyone would love to see an email killer come along Can you explain this? I've heard this sentiment before and never really understood it. The common complaints I hear about email are usually inherent in the fact that it's a universal communication mechanism[0], or a symptom of inadequate clients[1]. I can understand the need for better email clients (that's what Gmail originally was, back in the day[2]).…

IMO you don't experience email's failings until you setup an email server. Compared to any other network service I've setup, email is a huge PITA. Setting up the MTA with proper spf, dkim, IPs with a good reputation, and incoming encryption plus the MDA/Imap server with encryption and spam protection. It is a lot of work.

I've love to see something replace email with something that is simple to setup and administer.

As a user of email I don't really have a problem with it.

Re: Scaling email transparency

#19

Post by derefr »

grey-area wrote: post #12
derefr wrote: post #11

Earlier quoted context omitted.

> Maybe even mail uploaded to a server and not sent across the wire unless actually requested - why do we need to send messages when I might be able to infer from metadata that I don't want to read it 50% of the time? If you go there, you're basically talking about something that's more like blogs with RSS feeds, rather than email. To me, half the point of email is that it is "pushed": this allows to send messages to…

You could push the fact there is a message at date n from x with subject y to the recipient servers without wasting bandwidth on the message itself along with attachments before you know it will be read. This would also have other effects (possibly delete/modify after send, invert control from the recipient to the sender etc), so it certainly would change the way email is used - probably not everyone would agree with…

I would think that if you're already going to do the SMTP transaction, the average (plaintext) email message body is small enough to slide into the same packet as the end of the transaction headers. It's the same as keeping the data of small files inside their directory-entry structures on disk.

On the other hand, it would indeed be interesting if email was simply a "unicast presence notification" channel to allow accounts to publish knowledge of a (private, ephemeral, encrypted, authenticated) message channel to other accounts, and then messages flowed via automated subscription-based pull. You'd still want your MUA to be a web service with active background polling, though (like cloud RSS reader services), since otherwise a user could send a message and then "retract" it from their feed before your own client had retrieved it.

But this would solve at the very least the spam problem: you could simply unfollow a channel that's sending you email, and receive no future messages on it. It'd be like every (sender, receiver) pair having its own dedicated inbox, that the true receiver consumes only voluntarily.

Post reply on HN