Email is one of the most common examples of Asynchronous Communication people are familiar with today. It is a store-and-forward approach which is tolerant of temporary disruptions to services and supports multiple hops.
Email is also a distributed system, supporting many different servers and providers. However, market forces have caused Google and Microsoft to have an outsized influence on email, and their algorithms and policies make it increasingly difficult for independent mail servers to be interoperable with them.
Email can run over many transports. SMTP and IMAP over the Internet, of course. UUCP and NNCP also can be used to transport email, and interoperate with Internet-based systems.
More about the asynchronous nature of email can be found in the Asynchronous Communication page.
Links to this note
I loaded up this title with buzzwords. The basic idea is that IM systems shouldn’t have to only use the Internet. Why not let them be carried across LoRa radios, USB sticks, local Wifi networks, and yes, the Internet? I’ll first discuss how, and then why.
I sometimes see people read about NNCP and wonder “This sounds great! But… what can I do with it?” This page aims to answer those questions.
This started as a post on my blog. This edited version is intended to be kept more up-to-date.
Arguably the most successful platform whose code can be easily modified at runtime. Emacs presents this through the metaphor of a text editor, though the Emacs platform has been about more than that since pretty much its inception. Emacs as a platform hosts email readers, Usenet clients, web and Gopher browsers, games, terminal emulators, sftp clients, chat clients, and even a window manager. With org-mode, most of these (including the email clients) can be linked together with agendas, task lists, and personal notes to form an integrated tracking system. org-roam extends this yet further.
Asynchronous communication is communication between two endpoints that doesn’t have to happen in real time or near-real-time.
According to the NNCP documentation, NNCP is intended to help build up small size ad-hoc friend-to-friend (F2F) statically routed darknet delay-tolerant networks for fire-and-forget secure reliable files, file requests, Internet Email and commands transmission. All packets are integrity checked, end-to-end Encrypted, explicitly authenticated by known participants public keys. Onion encryption is applied to relayed packets. Each node acts both as a client and server, can use push and poll behaviour model. Also there is multicasting area support.
Old technology is any tech that’s, well… old.
This started out at a post on my blog. This edited version is intended to be kept more up-to-date.
Inspired by several others (such as Alex Schroeder’s post and Szczeżuja’s prompt), as well as a desire to get this down for my kids, I figure it’s time to write a bit about living through the PC and Internet revolution where I did: outside a tiny town in rural Kansas. And, as I’ve been back in that same area for the past 15 years, I reflect some on the challenges that continue to play out.
UUCP is a system for exchanging data and requesting remote execution. It dates back to 1979, and was primarily used over Modems using telephone landlines for most of its days of popularity. It is an Asynchronous Communication system, which transmits data from one machine to the next on the way to its destination. Each intermediate node may store the data before passing it on to the next.
NNCP lets you securely send files, or request remote execution, between systems. It uses asynchronous communication, so the source and destination need never be online simultaneously. NNCP can route requests via intermediate devices – other NNCP nodes, USB sticks, tapes, radios, phones, cloud services, whatever – leading to a network that is highly resilient and flexible. NNCP makes it much easier to communicate with devices that lack Internet connectivity, or have poor Internet.