You are likely right about all of these things. I agree commercial E-mail providers don't currently have a reason to offer JMAP support. Thunderbird already has robust IMAP support so why change it. But JMAP provides a new avenue to E-mail client development that is both easier for existing clients to deal with and encouraging for new development.
hrm, handful of new github stars in one day?
That's odd. Must have gotten picked up by something.
Oh, HN repost of a blog post I wrote 3 years ago, cool!
To sum up my thoughts about this thread:
Appreciate the great discussion! Wherever you land on the validity of JMAP, as a long (long) time IMAP client developer I stand by my position that JMAP is a huge improvement over legacy IMAP. Not perfect, but walks a reasonable line between what IMAP client devs understand and the modern world of APIs 30 years later. Is it REST compliant or a SOAP derivative? Most likely no and yes. Does it only benefit client developers? Probably, but that is a big benefit to the E-mail ecosystem. IMO the biggest barrier to new and innovative E-mail clients is the obtuseness of the protocol itself, and JMAP goes a long way to bridge that gap.
Hello, author here! Not sure who posted this old blog article but great to see an interesting discussion and new interest in the project. Development is active and we always appreciate new feedback!
Sentiment analysis is not new, and I would imagine it's ancillary at best to a proper trading outfit. Well equipped market makers and HFTs make money on price movement (and exchange rebates). A flurry of out-of-the-money calls is unlikely to adjust an underlying equity price significantly enough to be statistically important.
Yep. Also I think they are using it for a subset of customers. While JMAP support in Cypht is still new, so far it's working just like IMAP, but my testing is limited since I just wrote the integration :)
I checked out the git source and built it from there. It was non-trivial to get it built and configured properly for JMAP, but I wanted the latest as the spec is still in flux.
I have been running Open Source projects for about 15 years, which implies moderating the communities around those projects (in my case, very small communities). I'm familiar with toxic environments. I once sent a very stupid question to the qmail mailing list - it did not go well for me. But I learned a lesson from that beat-down.
I make serious efforts to create an inclusive environment for my projects because that is what Open Source software is all about IMO. Any contribution deserves respect, it's a gift to the project. Maybe the PR needs some work, maybe it's total crap - but it's a gift either way and that should be respected.
It makes me sad to think people feel the need to maintain private repos just to avoid potential conflict with project maintainers because of toxic environments - but I understand that is a reality. I would like to counter that with the fact that not all projects are run that way, and some are very willing to accept contributions.
> It makes me sad to think people feel the need to maintain private repos just to avoid potential conflict with project maintainers because of toxic environments - but I understand that is a reality.
So you get sad for me because I am tired, burned out and want to get stuff done without the inevitable drama so many people feel they have to inject in everything?
Thank you for being sympathetic. ;)
This was half-sarcastic / half-serious.
---
On a totally serious note, you cannot at all blame anyone for wanting less -- or zero -- emotional baggage added to what should be a professional exchange of code and conversation points. I seriously cannot and will not care if somebody has a shitty life and spouts poison at me because I try to be helpful and they have nobody else to vent at the moment. I refuse to participate in a free therapy / rage unloading session with them.
As we get wiser, we start to get economical with our energy expenditures. Even more conservatively so with emotional expenditures. That one can feel like total crap after even one hour of drama is a harsh reality -- and the fact that many of us choose to avoid ruining our day is absolutely our right.
Blockchain actually could be used to provide data integrity in a distributed environment with known bad actors (presuming that they fall under the 50% threshold), but that is not applicable in this case since archive data is not stored in a distributive fashion by clients (as far as I know). Having worked on a production application that uses blockchain, my take away was it cleverly provides distributed ledger transparency, but at a price that makes it very inefficient as a data store.
