3 ms·

Computational mail for computer-supported cooperative work (1992)

27 points by codetrotter 4y ago

codetrotter 4y ago
The link posted here https://www.guppylake.com/~nsb/CSCW-ATOMICMAIL.txt 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 https://dl.acm.org/doi/pdf/10.1145/143457.143463 which has a couple of pictures at the end.
codetrotter 4y ago
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.
- lisper 4y ago
  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.
  - zwieback 4y ago
    I would argue that SMS is the other popular standardized push protocol.
    - lisper 4y ago
      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.
      - zwieback 4y ago
        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.
        lisper 4y ago
        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.)
        codetrotter 4y ago
        But is the cell network ultimately different from the Internet? You have to pay an ISP too, to connect to the Internet.
        actionfromafar 4y ago
        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?)
RedShift1 4y ago
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.
- messe 4y ago
  > 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.
- theamk 4y ago
  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.
- st_goliath 4y ago
  > 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
  - ReactiveJelly 4y ago
    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?
- soneil 4y ago
  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.

27 points by codetrotter 4y ago

The link posted here https://www.guppylake.com/~nsb/CSCW-ATOMICMAIL.txt 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 https://dl.acm.org/doi/pdf/10.1145/143457.143463 which has a couple of pictures at the end.

codetrotter 4y ago

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.

lisper 4y ago
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.
- zwieback 4y ago
  I would argue that SMS is the other popular standardized push protocol.
  - lisper 4y ago
    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.
    - zwieback 4y ago
      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.
      - lisper 4y ago
        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.)
        codetrotter 4y ago
        But is the cell network ultimately different from the Internet? You have to pay an ISP too, to connect to the Internet.
        actionfromafar 4y ago
        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?)

RedShift1 4y ago

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.

messe 4y ago
> 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.
theamk 4y ago
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.
st_goliath 4y ago
> 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
- ReactiveJelly 4y ago
  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?
soneil 4y ago
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.