Subj : Re: Is binkp/d's security model kaputt?
To   : apam
From : tenser
Date : Thu Sep 23 2021 02:01 am

On 22 Sep 2021 at 02:07p, apam pondered and said...
 
 ap> I don't particularly care about mystic either (as you know), but don't
 ap> want to lose those who seem to be tethered to it.

That's fair.  I'm not suggesting leaving those people stranded,
but rather, providing an alternative mechanism for those so inclined.

 ap> and while building something on top of HTTPS would be fun, it's kind of
 ap> pointless if no one uses it.
 ap> 
 ap> I got all excited by this idea a few days ago and started adding "json
 ap> exporting" to postie (my mail tosser / scanner) and learning go to make a
 ap> server/client, but the enthusiasm has fizzled a bit (mainly due to other
 ap> stuff preoccupying my mind)

That's the fundamental problems: time and wondering who would use it?

 ap> Plus, I don't really know the best way to do the transmission, I was
 ap> thinking just using POST with a node number and password and having the
 ap> server respond with json messages in the response.

Well, I think the way to do it is a multiphase protocol:

1. Connect and authenticate.  This would, presumably, mean POST'ing
   credentials and getting back a session token of some kind.
2. Post to an "offer" resource, with a list of things to offer
   the distant end.  Note that the response to an HTTP POST
   can itself contain data; presumably that would be a list of
   dispositions for things things offered:
   a. send + URI: send this now by PUT'ing to the given URI
   b. reject: do not send and do not offer again
   c. defer: do not send right now, but try again later
3. A sequence of PUT's to the URI's retrieved for "send"
   responses from (2).  The HTTP response to the PUT would
   indicate successful receipt on the remote end, or failure
   with a try-again-later, or whatever.
 
This takes care of the things that are offered to the distant end,
we now move onto a phase of retrieving from the remote side.
It's essentially the same protocol, just in reverse and with one
extra step.

1. Perform an HTTP GET on the "offer" resource; the result is
   a list of resources and URIs offered by the remote end.
2. For each resource the local end is interested in retrieving,
   issue an HTTP GET for that resource.
3. Once everything has been retrieved, we issue an HTTP POST
   to a "finalize" resource with the disposition of the things
   offered; either accept (meaning successfully accepted),
   reject or defer (as before).  You need the extra step in this
   phase since you can't rely on HTTP response codes to indicate
   the disposition of a requested resource.

That's basically it.  Using HTTP pipelining, there aren't many
more "synchronization points" compared to binkp, one gets all of
the HTTP functionality (compression, encryption, authentication,
but also caching and proxying etc) for free, and you get streaming
in a way you don't get with binkp.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.