== Why email is often not as good as modern communication protocols I was recently reading [[Git is already federated & decentralized https://drewdevault.com/2018/07/23/Git-is-already-distributed.html]] ([[via https://lobste.rs/s/h1udkf/git_is_already_federated_decentralized]]). To summarize the article, it's a reaction to proposals to decentralize large git servers (of the Github/Gitlab variety) by having them talk to each other with ActivityPub. Drew DeVault ntes that notes that Git can already be used in a distributed way over email, describes how git forges could talk to each other via email, and contrasts it with ActivityPub. In the process of this article, Drew DeVault proposes using email not just between git forges but between git forges and users, and this is where my sysadmin eyebrows went up. The fundamental problem with email as a protocol, as compared to more modern ones, is that standard basic email is an 'anonymous push' protocol. You do not poll things you're interested in, they push data to you, and you can be pushed to with no form of subscription on your part required; all that's needed is a widely shared identifier in the form of your email address. This naturally and necessarily leads to spam. An anonymous push protocol is great if you want to get contacted by arbitrary strangers, but that necessarily leads to arbitrary strangers being able to contact you whether or not you're actually interested in what they have to say. This susceptibility to spam is not desired (to put it one way) in a modern protocol, a protocol that is designed to survive and prosper on today's Internet. Unless you absolutely need the ability to be contacted by arbitrary strangers, a modern protocol should be either pull-based or require some form of explicit and verifiable subscription, such that pushes without the subscription information automatically fail. (One form of explicit verification is to make the push endpoint different for each 'subscription' by incorporating some kind of random secret in eg the web-hook URL that notifications are _POST_ed to.) It's possible to use email as the transport to implement a protocol that doesn't allow anonymous push; you can require signed messages, for example, and arrange to automatically reject or drop unsigned or badly signed ones. But this requires an additional layer of software on top of email; it is not simple, basic email by itself, and that means that it can't be used directly by people with just a straightforward mail address and mail client. As a result, I think that Drew DeVault's idea of using email as the transport mechanism between git forges is perfectly fine (although you're going to want to layer message signatures and other precautions on top), but the idea of extending that to directly involving people's email boxes is not really the right way to go, or at least not the right way to go by itself. (To be blunt, one of the great appeals of Github to me is that I can to a large extent participate in Github without spraying my email address around to all and sundry. It still leaks out and I still get spam due to participating in Github, but it's a lot less than I would if all Github activity took place in mailing lists that were as public as eg Github issues are.)