Item — HN Reader

The author notes: "Finally, we need to talk federation. Does it make moving fast and breaking things more difficult? Yes, yes it does, and that can be a good thing."

The other, super-underrated feature of federated systems is that antagonistic parties are willing to use them together. For example, the US military, Russian government, major international banks, Google, Facebook, etc ALL use email and happily exchange messages over SMTP. There's no centralized service you could get all these parties to agree to use (not even Signal).

The result of this is that everyone has an email address, and that makes it the universal standard for business-to-business communication. I can loop in any number of parties on a single thread from all over the world and it just works.

My startup Shortwave is trying to build a messaging future that is email. We're trying to evolve and upgrade email to have the look and feel and features of a product like Signal, but with all the universal, federated goodness of the global SMTP network. It's a long project -- federated systems evolve slowly! -- but it's the bright open future I think we need. I go into some detail here: https://www.shortwave.com/blog/future-of-messaging/

8 comments

> We're trying to evolve and upgrade email to have the look and feel and features of a product like Signal

Please don’t. Email is not a chat.

This. I've long advocated for and would be delighted to have an "Email" that was identical to current email except with cryptography built-in from the ground up, with public certs for any given domain based simply on DNS and coordinated through the server for that domain. Otherwise the same as email. It doesn't need to be "evolved" and "upgraded" beyond that, everyone is fine with and understands email already. At most I'd add "no remote resources", or a standard system around "so and so wants to talk to you" to make it easier to do whitelist/greylist, a standard API for 3rd party vouching services, all things to help transparently cut down on spam ahead of time.

But overall less is more here. There is certainly a place for real time messaging/chatting/rich collaboration services as well, but they aren't "electronic mail". The focus should be on making a standard and then model implementations that work very well.

It'd be nice if we could either have a better subset of html/CSS support, or find a simpler content type for email content that isn't 80-chars-wide-and-monospaced, but isn't full html.

The problem is that big tech would all need to get behind a concerted effort to improve email, but they have no incentive to strengthen a decentralized, nonproprietary communication medium.

It would be nice to have a standard for delivering email-like messages over Matrix, with email-like clients rather than chat-like clients. The protocol itself would support it.

Isn't the whole concept of Matrix to be a DAG of messages with hashes for tamper-resistance (ie a Merkel tree) to secure the history in the presence of many servers, some of which might exhibit Byzantine failure?

What is the point of any of that for 1-to-1 communication?

It's a general Merkle DAG, not a tree. This is because two homeservers can append nodes to the DAG at the same time. The state resolution algorithm ensures all homeservers in a room eventually agree on a consistent state despite receiving nodes in an inconsistent order

It's fairly useless for 1-to-1 communication. But for any group communications, it means there's no one server that can go down that will take down the whole room (unless all the participants are on the same server); contrast with XMPP MUCs.

On the other hand, XMPP is a lot faster.

because users generally own more than one device.

All of a user's device still go through the one "homeserver" which is the only party doing the federation. If the multi-party stuff is client-to-server, again the Merkle tree is useless.

> an "Email" that was identical to current email

Please don't. Current email is a mess. One person's email client will set the email background to dark gray and another person's email client will have a dark grey background and the result will be unreadable. One person's email client will put the quoted text at the bottom and another person's client will put the quoted text at the top and the thread will be unreadable. A sender's email client will use quotes in a way which a receiver's client doesn't understand and the receiver's client will show a thread view where each message in the thread also contains a copy of all previous messages in the thread. The sender's email client will use a symbol font which the receiver doesn't have so that symbols look like random letters to the receiver.

Email is terrible. It does need to be radically overhauled. The lack of cryptography is far, far from its only problem.

Plus there's the spam problem, which means you won't be able to send email reliably unless you're a major company. It's federated, but only multinationals are allowed to play.

I think the parent meant identical in concept, not in the technical format. All the valid points you raise could be fixed with a new format and related conventions without changing what email is conceptually (e.g. distributed threaded long-form asynchronous decentralized communication with Subject/To/Cc etc.), as opposed to turning it into a chat system.

> I think the parent meant identical in concept, not in the technical format.

That might be true. But I feel like a lot of email proponents have this idea that email is actually pretty good, when in reality, email is an unmitigated disaster and sorely needs drastic changes on the technical front.

Email is not a disaster in user communities with established conventions, such as B2B (and intra-B) communication and open-source/unix-oriented mailing lists. People in those communities see how systems like Slack and Discord and Signal are completely unsuitable to replace the email mode of communication, and therefore there is a pushback against those who push for such a replacement.

Yet for 99% of regular people, email is a complete disaster, and the people who are in extremely insular communities (such as certain FOSS projects) don't realize just how broken email is. There _is_ need for a replacement, since email plain doesn't work.

> We're trying to evolve and upgrade email to have the look and feel and features of a product like Signal, but with all the universal, federated goodness of the global SMTP network.

This already exists. It's called Delta Chat. Please don't make your product incompatible.

> email still has two key advantages

Three, actually; the third is that email is an asynchronous, store-and-forward system. That feature makes it unsuitable as the basis for an "instant chat" system. It also makes it challenging to put e2e encryption on email.

Asynchrony is the feature I most value in email. I can send you a message if you're in the bath, if your device is switched off, or if you're AFK for the next 3 months. You can read it on your desktop, mobile device, or in a web cafe. I don't use chat, and I don't like SMS (which anyway only works with a SIM, so on a mobile phone; and your identity is tied to a specific SIM).

The problems with email, as I see it, are:

- text/html. HTML email has always sucked. It's the devil to craft HTML that works in programs like Outlook. And it's full of vulnerabilities.

- Encryption. You can't e2e-encrypt email headers, because they're needed by intermediate nodes for routing. GPG/PGP has a horrible trust model, that deters people from using it (I've never really looked into S/MIME).

Isn’t that just the Matrix protocol then? I think the hard part is adoption.

DeltaChat?

I loved the idea of Delta Chat, but it ate some non-chat emails and wouldn't reliably notify me of new messages.

But as far as holding conversations, it worked alright, though I missed having a typing indicator.

Looks like this is built on the gmail api? Any plans to support Office 365?

How well does this approach work when communicating outside your organization with non-shortwave users? Seems challenging to degrade the experience gracefully.

So basically deltachat?

Are open shameless plugs like this allowed on hacker news without disclosure?

Open shameless plugs are a long and storied tradition on Hacker News. Full disclosure: I run a startup that specializes in shamelessly plugging your startup. Contact deets in profile.

> My startup Shortwave

Sounds like disclosure to me.

I would have avoided the shameless plug here if it wasn't so very topical... :)

Relevant plugs are always welcome on HN.

Probably, the upshot is I know to not bother with whatever is being plugged

Yes. It's just typically not well received.

It’s fine if it’s on-topic I think? In this case it’s on topic.

Isn't "My startup Shortwave" enough disclosure?