jasonmunro

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.

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.

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

Nope, you are exactly correct. JMAP is just a much more modern and efficient way to connect clients and servers to access E-mail.

JMAP actually does support replacing both. My next TODO item for Cypht is integrating SMTP support with JMAP.

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.

A digital library sort of implies centralizing? I think this thread explores how you can contribute to decentralization of the hosted content:

https://news.ycombinator.com/item?id=17685682

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.

This will be my first year attending the annual event, and I'm super excited! I'm a long time fan of the Wayback Machine, even though my early work is terribly embarrassing :) Love what the archive does, which is so much more than snapshots of old websites. If you somehow have not read the mission statement, it's worth a minute: https://archive.org/about/

Your points are valid, but not entirely correct IMO. What you are describing as abuse is "quote stuffing". Sending in buy or sell orders to move the market with no intention of fulfilling said orders. When I worked for an exchange operator we routinely reported this type of abuse to the SEC. It' difficult to discern the difference between a fast moving market maker (and many successful HFT firms are indeed market makers) and simple re-positioning of the spread because of shot term volatility. Your "evil" HFT firms may be abusing the system by cancelling an order placed a millisecond prior, but they don't make any money if a trade does not occur. Quote stuffing without a trade on the modified price does not produce a profit. Manipulating the market in this way is not a fool-proof way of making money - there still has to be a minimal position taken by the trading firm in order to realize a profit.

No exchange operator is doing "gods work" :) Seriously though, you are correct. Market makers are an integral part of how the markets function. Do they skim money from trades because they are better equipped to read the market at a given point in time? Absolutely. Do they also provide liquidity for the retail trader in a given moment to buy/sell shares? They definitely do. Market makers are not a new facet of trading systems, they are just a natural fit for HFT firms. Would it be better for your order of X shares of N company to go unfilled, or to pay .01 cents more per share to have it executed when you want?

The liquidity comes from the HFT market maker's own money. Market makers are required to post bid and offers of a reasonable level of liquidity in all symbols they are registered to "make markets" in. It may seem like a simple skim off the top operation, but it's not that simple. If they do not maintain their bids/offers, they are disqualified from market making.

If they do maintain them, they reap a number of benefits including discounted pricing from trading platforms and IIRC, the ability to do naked short selling (which IMO should be off-limits for all trading firms). I'm not defending HFT here, just stating a fact that market makers are a part of the trading ecosystem.

Keep in mind that "making" and "taking" liquidity is not the same thing as buying and selling. Market makers are required to post both bids and offers. The difference is that market makers put their orders (buy or sell) on the "book", which means they are offering liquidity in both directions. The order that comes in to match (think "market" order to buy or sell) is the "taker". Firms that supply liquidity are rewarded by trading platforms (unsurprisingly, since those firms "make" their market), and firms that match those orders (takers), are charged for the service.

Not all HFT outfits are "market makers", but many are. I can't say specifically if Virtu is a market maker, even if I remembered :) The point is that liquidity providers don't pay for their trades, they are paid for them, so it's a natural fit for a smart HFT operation.

Firms with enough money to spend _can_ get a more accurate view of the market. The issue is proprietary data feeds. A trading platform is required to disseminate information to the consolidated tape at the same rate they do for a private feed, but that only holds for the "walls" of the trading platforms network. The consolidated tape is a LOT slower than a 100MB multicast feed being slurped up by a co-located server sitting 20 feet from the trading system.

While it's true that stock exchange operators are private companies, they are also SROs that undergo significant scrutiny from various government organizations (FINRA, SEC, etc).

Most (all?) exchanges use "maker/taker" pricing, so while it is possible the trading platform might not make money on _every_ trade depending on the exact pricing rules, they do make money in the aggregate, and in general more trades equal more profits. Many of the opponents to HFT believe that the maker/taker pricing model is a big problem in the markets, and doing away with it would significantly curb HFT profits. Personally, I'm ambivalent about HFT. All stock trading seems to me far removed from the actual value of the underlying companies anyway :).

Disclaimer: I was an engineer at BATS Global Markets for 5 years, but have been out of finance for the last 4, so my info may be out of date.

I'm terrible at naming things. It is supposed to be a homophone for "sift", and it's just odd enough that the domains were super cheap :) I toyed around with adding a phonetic "sift" under the logo on the site, maybe I should revive that effort.

We have an open issue at github for PGP support, and it's something I definitely want to pursue. The big concern is private key security and how to balance that with usability.

I felt that it most accurately represented my intentions for the software.

I did not, thanks for the info. Looks interesting.

I appreciate the suggestion, and will get a screenshot page added to the site. In the meantime, here are a few blog posts with more shots:

https://unencumberedbyfacts.com/2016/09/08/cypht-webmail-scr... https://unencumberedbyfacts.com/2016/10/04/cypht-webmail-scr...

Wow, thanks for the kind words! I submitted this last night hoping to drum up some support for the project. I never dreamed it would be on the front page when I woke up!

Thanks for the feedback, and I agree. I love the idea of a docker image to create a demo environment.

Also, thanks for the Oauth2 recognition. It's perfect for a client like Cypht (I wish more providers supported it!).

Thanks for your feedback! Cypht is a thin client that only accesses E-mail using IMAP (or POP3). No E-mail content is maintained locally except in the server side session, and the browser local storage (session only). Cypht does store your E-mail account credentials between logins if you chose to (this behavior can be disabled). Outside of that, we only aggregate content in the browser, not on the server or in any permanent manner. There is a performance price, but it's worth it IMO.

This project has been a labor of love for me over the last 2.5 years. I'm interested in any feedback you have, and happy to answer any questions!