[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)