Computational mail for computer-supported cooperative work (1992) | Hacker News Reader

Computational mail for computer-supported cooperative work (1992)

guppylake.com

27 pointscodetrotter18 comments

I am sharing this link because I think it is interesting how close many of the things said here, in 1992, are to what ended up happening.

> What is really needed is a platform on which distributed applications can be built without concern for the problems of distribution, user buy-in, and heterogeneous interaction environment.

> […]

> One solution is to "piggyback" the engine on top of a technology that is already at the fingertips of most computer users today, electronic mail.

This is more or less exactly what happened. Except it ended up happening not on top of email but on top of www.

One of the things that the world doesn't seem to have realized yet even thought it should be glaringly obvious by now is that when designing protocols for electronic interactions one must choose carefully when to push and when to pull. Email is push-only. HTTP is pull-only (or at least it was when it started out). To really do the Right Thing you need both working together. And there are two rules that should guide the design:

1. Push should only be used when it is necessary to draw the user's attention to something in a timely manner.

2. Push should never transfer large quantities of data. Large quantities of data should always be pulled, never pushed.

Email violates both of these principles, and HTTP doesn't have push at all.

The real problem is that email is the only push standard that is both open and widely deployed. Everything else is either proprietary (Twitter, iMessage, SMS) or niche (mastodon) or both.

I would argue that SMS is the other popular standardized push protocol.

Yes, I mentioned that in my OP. It's standard, but not open. You can neither send nor receive SMS over the internet without paying a third party.

Oh, I didn't know that. So those services where you send an email to an address and it shows up as an SMS are not generally open? Yeah, I guess that would move it into the proprietary column.

Nope, those are all run by the cell carriers. If you change carriers, your SMS email gateway address changes too.

(There are some services that try to be carrier-independent but they eventually have to interface with the carriers somehow. There is no way to send an SMS that doesn't eventually end up in the (proprietary) cell network.)

But is the cell network ultimately different from the Internet?

You have to pay an ISP too, to connect to the Internet.

I can't formulate a technical reason why there is difference.

I guess I have to go with culture... there are very few if any systems which talk to each other over SMS. Definitely not in a standardised manner, if so. Custom SCADA systems, maybe.

(SMS is more like how modems were back in the day, re automated systems.)

So there are very few apps on SMS today. Almost all communication is either machine system > human. (Spam, 2FA, etc.) Or human <-> human.

Edit:

in a parallel reality where we were stuck on SMS for some reason (alien invasion in 1989, successfully repelled but much of value was lost, for instance) and SMS messages were to become cheap or free (as they often are today) I could definitely see an "internet" growing up with SMS as the transfer backbone.

Much of the basics could be done over SMS, status updates, "email", news and so on.

Heck, Twitter ran on sms I'm told. (It was a US thing, right?)

The cell network is radically different from the internet.

1. You need a SIM card to connect to the cell network. There is no cell-network equivalent of "free wifi".

2. If you have a (paid) internet connection you can net anyone connect to it with their own hardware. You can't share a cell network connection that way.

3. The internet is packet-switched. The cell network is (mostly) connection-based.

4. The cell network lacks broadcast and multicast protocols.

5. Cell network connections are always peer-to-peer. You can't have a "server" on the cell network. The concept doesn't even make sense.

I could go on and on.

Free WiFi equivalent exists when you call 112 emergency services.

No sim required, any cell tower from any carrier will allow the call.

Heh recently I wondered why we don't use SMTP to send for example telemetry data around. It has everything for reliable message delivery. Instead I went with MQTT for the latest project that collected telemetry data and shoved it into a database, out of fear the next admin would come to hunt me down for using SMTP for a thing like this.

> out of fear the next admin would come to hunt me down for using SMTP for a thing like this.

Why would they need to hunt you down? If you’re actually implementing SMTP sensibly, they could reach you via the Reply-To address.

SMTP will be fine if you just use a protocol and set up all new parallel infra. Overhead will be quite a bit higher but that's not a problem in modern world.

But sharing the existing email infra is pretty dangerous. You never know when spam filters decide to filter your messages and turn your "reliable" message delivery into black hole.

I used to work with a platform that used smtp for telemetry (ish, event-based rather than stream-based). I'm not sure I'd ever do it again. It was essentially email alerting, but I consider it a close equivalent because the messages were sent machine-to-machine and (hopefully) never surfaced to a human, and they were sent realtime with no rate limiting (sent realtime, where reception is anything but).

The single largest issue we had was that customers would use their own email address as the Sender as it was the easiest way to have it accepted by their own network. And then if anything went wrong with our MX, customers would get thousands of bounces back to their address.

But the cause of a lot of issues is that mail does not have reliable delivery. The sending device cannot promise the email was delivered, only that its session with an smtp server ended without fault. It can't promise the message was forwarded or delivered (I have seen mailservers accept emails and disappear them), It can't interrogate the chain of custody from end to end. Receiving email is a near-unrelated second path that rarely exists in embedded applications, so the bounce/feedback mechanism is rarely a closed loop in these applications.

The way I envisioned is that the entire thing would be separate from the regular public email system. The collecting device would first deliver it to a local mailserver, which then in turn delivers it to our mailserver which only accepts TLS connections with a client certificate signed by us.

> Instead I went with MQTT for the latest project that collected telemetry data ...

If you want broadcast-message-to-topic-subscribers style semantics, you could have [ab]used IRC for this, rather than SMTP :-P

Pretty unreliable [1] though. I'd sooner build some custom HTTP thing in front of Postgres or SQLite than try to do resending over IRC, a protocol which badly suffers from a fuzzy separation between payload and protocol.

[1] If you lose connection, neither side is sure which messages they missed, and replaying is not part of the protocol. If you're gonna support a memo bot, why not build it in?

The link posted here https://www.guppylake.com/~nsb/CSCW-ATOMICMAIL.txt is the plain-text version

See also the pdf at https://dl.acm.org/doi/pdf/10.1145/143457.143463 which has a couple of pictures at the end.

Reply on news.ycombinator.com