[HN Gopher] IMAP API - Self Hosted Nylas/Context.io Alternative ...
       ___________________________________________________________________
        
       IMAP API - Self Hosted Nylas/Context.io Alternative to Access IMAP
       over REST
        
       Author : andris9
       Score  : 28 points
       Date   : 2020-03-01 20:50 UTC (2 hours ago)
        
 (HTM) web link (imapapi.com)
 (TXT) w3m dump (imapapi.com)
        
       | nolok wrote:
       | Can anyone tell me if the license as given
       | 
       | > Licensed for evaluation use only
       | 
       | Is clear enough in legal terms for what can or cannot be done ? I
       | assume it means it's free to use to test it and see how it works,
       | but not for anything else ? Does that cover the code too ?
        
         | andris9 wrote:
         | It mostly means I haven't yet figured out which kind of
         | license/terms to use for this project. TBD.
        
         | godzillabrennus wrote:
         | Basically, as a lay person, to me this means it's not licensed
         | for use in anything you care about.
         | 
         | Fine for playing around with on your computer but not
         | integrating with anything productive.
         | 
         | This is not legal advice though. Always consult a lawyer if you
         | have legal questions.
        
       | pouta wrote:
       | All I can see is I'm a papi .com
        
       | dochtman wrote:
       | Any IMAP over REST API should just implement JMAP (RFC 8620 and
       | 8621).
        
         | rakoo wrote:
         | Indeed. Which is the perfect occasion to ask: who besides
         | Fastmail implements it ?
        
           | brongondwana wrote:
           | Right now - not heaps.
           | 
           | https://jmap.io/software.html has a list of some known
           | implementations.
        
             | detaro wrote:
             | https://github.com/jmapio/jmap-perl seems the most similar
             | to the project discussed here. Anyone have experience with
             | it?
        
               | brongondwana wrote:
               | It was largely written in about a week, a few years ago.
               | It's quite stale now unfortunately. It was updated to the
               | current RFCs for mail, but it's still on a very old
               | Calendars version.
               | 
               | The downside of the JMAP model for a proxy to IMAP is
               | that you do need to have a bit of state in your proxy
               | server. jmap-perl uses a sqlite3 database per user for
               | storing that state.
               | 
               | Structurally, it's a non-blocking server in front of a
               | forking server - the non-blocking handles connections and
               | event streaming, and opens multiple backend forking
               | servers per user, one for reads, one for writes, and one
               | for background syncing/import.
        
         | andris9 wrote:
         | There is only a handful of IMAP server implementations and
         | there are going to be even fever JMAP servers. It is super
         | bloated, the RFCs 8620 and 8621 are already 200 pages in total.
         | Not an easy thing to integrate with.
        
           | brongondwana wrote:
           | To be fair, RFC3501 is 108 pages, and the bis (draft-ietf-
           | extra-imap4rev2-12) is 157 pages. It's a complex problem
           | space.
           | 
           | I'm looking forward to getting JMAP Calendars and JMAP
           | Contacts done, at which point is becomes a much more
           | compelling replacement for multiple protocols.
        
             | toomuchtodo wrote:
             | Anything we can do to help in getting those other
             | extensions done?
        
           | inputmice wrote:
           | The problem JMAP is addressing is quite complex that's why
           | the JMAP spec is long. I do not however find it to be
           | bloated. On the contrary I actually found it quite easy to
           | read. (I've implemented jmap-mail on the client side.)
           | 
           | One could potentially write JMAP as a proxy to an existing
           | IMAP server (just like your 'imap-api') therefore the current
           | lack of JMAP servers doesn't really matter.
        
             | andris9 wrote:
             | It is easier on the client side as you'd only have to
             | implement the parts you actually need. In server side if
             | you want to expose JMAP then you'd have implement
             | _everything_. You can't decide for example that as no-one
             | actually copies messages but moves, then you'd skip the
             | copy endpoint.
        
               | josephg wrote:
               | I had a chat with Neil Jenkins and Bron about this (two
               | of the authors & WG chairs). That skew is intentional -
               | their rationale is that there's way more email clients
               | out there than email server implementations. So it makes
               | sense to load more of the complexity into the servers.
               | 
               | Of course, until other email servers add support for
               | jmap, the protocol has a bit of a bootstrapping problem.
               | Getting support from gmail + microsoft exchange would be
               | a huge win for jmap, and in the long run email as a
               | whole.
        
       ___________________________________________________________________
       (page generated 2020-03-01 23:00 UTC)