Hacker News Reader

Comment by stilisstuk | Hacker News Reader

I feel a bit different: Email is a standard. You are talking about an app. Send later is the job of the application,not the standard. Same with reply all. Intelligent priority inbox is _hard_ but i. Principle the same.

When you use gmail you conflate the standard with the app.

View on HN

I largely agree with this, except that "Send Later" really does want some form of server support so it will happen even if you quit the app (especially on mobile). That said, there are third-party apps that do this, such as Spark (though they require storing your credentials on their servers).

Priority inbox is also something that can be done client-side. FWIW FastMail does actually have internal flags for "$ismailinglist" and "$isnotification" that you can access via advanced search, but they don't have any intelligent customization of these flags, no way to tell FastMail "hey this email was categorized wrong". You can write a Sieve script that adds/removes the flags yourself but that only works for stuff you can detect in a sieve script, i.e. no ML. Still, it's better than nothing when using the web app.

The Google way, aka masquerading flags as special folders seems to work good for non-aware clients.

IMAP actually has client-defined flags, but support on the clients is sketchy and not uniform

The point of these discussions is that the standard (IMAP specifically) is inadequate to a lot of modern use.

One good thing that Fastmail is doing is promoting a REST-like IMAP alternative ( https://jmap.io/ ) that makes it easier[1] to go back to the distinction application/protocol.

[1] by this I mean that implementing an app like gmail over IMAP would be a terrible idea, while JMAP would be at least a bit better (it also adds browser support as it allows HTTP as transport layer)

What, exactly, do you feel is deficient about IMAP vs. JMAP, other than the latter being a protocol that doesn't require a bespoke parser? The only thing even remotely semi-annoying about IMAP that I can think of is the way message identifiers are per-connection (but in some very important way that actually makes sense).

The only thing I know about IMAP are from JMAP, so I cannot say what is lacking in IMAP per se.

As far as I know a couple things that are pain points for me when using thunderbird/other IMAP clients (weird search limitations, strict folder hierarchy organization) are due to how IMAP was designed, but these are mostly minor issues that I imagine would not require a new protocol.

What I hope the advantage of JMAP will be is that it will provide a more flexible foundation for gmail-like interfaces on an open protocol.

At least all IMAP clients I have used have always felt... clunky and counter intuitive (I started using email with gmail, so maybe I just never learned the skills) even if IMAP already had all the good things JMAP claim, I think that the different focus on message and less historical baggage have a good change of producing designs that will feel more natural to me.

Being a stateless protocol is the big one, for mobile. There’s more: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/

That "stateless" paragraph in that article is explicitly referring to the per-connection message identifiers I was referring to; but that state burden is mostly carried by the server (which is put in the awkward position of dealing with separate clients with individual state sharing a mailbox) not the client (which by definition has a unique state anyway), which the article even admits.

I will argue that if you use the right data structures--not that anyone does--it really isn't that hard to make that work on the server, and the benefits to the client are actually enormous... particularly on mobile!

The way IMAP handles message identifiers allows for the client to pretend to manage a ridiculously large list of messages without storing any state locally that isn't visible on the screen (like it is _so good at this_ as Mark Crispin seriously intended the original IMAP protocol to be used by thin clients for mail: synchronizing mail over IMAP was never the intended usage model), as the entire problem of managing that consistent view has been pushed to the server (where it is solvable, just no one cares enough to even do a basic implementation correct much less a good one as everyone misunderstands and detests IMAP).

FWIW, the argument for how JMAP supports update batching over push notification channels is in fact interesting for mobile clients :(. That is so totally the fault of the mobile networks and OS people, though :(. The correct solution for that is to provide a flow control layer for wireless IP, at which point every app could be doing its own end-to-end encrypted push notification stuff without having to go through Apple/Google, but the incentive structure to centralize notifications through a middleman was just too great :/.

> push notification... That is so totally the fault of the mobile networks and OS people

The issue for mobile is that unrestricted push notifications are a serious battery drain. I think that JMAP makes the correct choice here, a push notification is just an external action/url, how the notification is delivered to the human is left out of the protocol. I would say that it allows for both openness and centralization without a bias for one or the other.

Yes, I both understood that, acknowledged it, and then not only noted that a better solution was available but actually sketched how that better solution would work ;P. Given the poor incentives on the platform players here, I will thereby repeat the part where I understand and acknowledge the issue, but am going to then once again note how sad I am that we are in a world that didn't just solve this issue in an egalitarian way that doesn't require middle-man (using a flow control layer for wireless IP, rather than simulating that using an oligopoly of middle boxes).

oh, the reason for my answer is that I implicitly assumed that something like `a flow control layer for wireless IP` capable of solving the problem could not exist. Or better I cannot even imagine how it could work.

My understanding is that a important property is that the device does not receive network packets that are not "replies". So that it has control on when it is fine to power down the network (in a very gross simplification)

So maybe something like what you are describing would be a protocol where the client can say "pin me back with this for this category of events but no sooner than X minutes", but at a network level, like a tagged TCP sleep function.

I never thought of this possibility. In the form I have imagined it it is technically inferior, but it would be an interesting approach to decentralization and surely could be improved.

I’ve never been able to search my entire mail archive quickly over IMAP, using Gmail or Fastmail. Mobile IMAP clients seem especially slow and inconsistent.

IMAP exposes a pretty comprehensive server-side query system. If your email is being synced locally then you aren't dealing with an IMAP limitation, as it isn't even using IMAP. If it is searching remotely, wither the email isn't being indexed for those searches or the client is doing some ridiculously poor search strategy. Like, if you actually look at the mechanism IMPA exposes for this, it is pretty powerful. (The only real limitation is that the original SEARCH mechanism is per-"mailbox", but this was fixed a long time ago with the SEARCHM extension. But arguably the correct way to map Gmail to IMAP is to put all your email in one "mailbox" and use IMAP "flags" as labels anyway.)

So I’m told, and yet searching my mail from the iOS mail app over IMAP is slow and unreliable, so I use the Fastmail app, even though it is slower to launch. Have you found a mobile IMAP client that works? notmuch [1] looks like it would solve my problems on the desktop, but searching from mobile devices is important to me.

[1] https://notmuchmail.org

Server-side search on K9 works fine, but you have to select that you want it.

The push mechanism, for one.

IMAP has one (two actually, IDLE and NOTIFY) but they are not really adapted to the way we use email today (mobile and browser-based apps).

With Fastmail you're essentially buying the app as much as the service.

If you want reliable email service without the nice app, there are much cheaper alternatives.

Such as?

I'm a very happy migadu.com user. Set fee for unlimited storage and unlimited addresses. Very simple but effective admin UI too.

https://purelymail.com/ I haven't try it yet, but it is only 10$ per year

$10/y seems ridiculously cheap. Too cheap. I'd be worried they may go out of business.

Mailbox.org

I’m a happy user and never touch the web app. It works, but a dedicated mail client is a superior experience.

Reply on news.ycombinator.com