[HN Gopher] Computational mail for computer-supported cooperativ...
       ___________________________________________________________________
        
       Computational mail for computer-supported cooperative work (1992)
        
       Author : codetrotter
       Score  : 20 points
       Date   : 2023-03-30 07:41 UTC (15 hours ago)
        
 (HTM) web link (www.guppylake.com)
 (TXT) w3m dump (www.guppylake.com)
        
       | RedShift1 wrote:
       | 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.
        
         | st_goliath wrote:
         | > 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 wrote:
           | 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?
        
         | theamk wrote:
         | 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.
        
         | messe wrote:
         | > 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.
        
       | codetrotter wrote:
       | 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.
        
       | codetrotter wrote:
       | 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 wrote:
         | 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 wrote:
           | I would argue that SMS is the other popular standardized push
           | protocol.
        
             | lisper wrote:
             | 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 wrote:
               | 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 wrote:
               | 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 wrote:
               | But is the cell network ultimately different from the
               | Internet?
               | 
               | You have to pay an ISP too, to connect to the Internet.
        
               | actionfromafar wrote:
               | 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?)
        
               | lisper wrote:
               | 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.
        
       ___________________________________________________________________
       (page generated 2023-03-30 23:01 UTC)