Subject: [Jmap] Mailbox.unreadThreads and messages not in a mailbox

From: Neil Jhaveri <[email-masked]>
Date: Tue, 7 Aug 2018 14:07:57 -0700

Mailbox.unreadThreads has the following fairly strict definition:

   o  *unreadThreads*: "PositiveInt" (server-set) The number of threads
      where at least one email in the thread has neither the "$seen"
      keyword nor the "$draft" keyword AND at least one email in the
      thread is in this mailbox (but see below for special case handling
      of Trash).  Note, the unread email does not need to be the one in
      this mailbox.

The aspect that unread messages not actually in a given mailbox would
affect the Mailbox's unread thread count is a behavior where I think there
might be some different opinions, without any “right” answer.

For comparison, Gmail.com calculates unread thread counts only based off
messages that are unread in the mailbox. I’m adopting Gmail's behavior in
the client I’m working on, since it’s geared to that service, but when
writing that functionality I noticed that there won’t be a great way for me
to get this behavior of unread thread count from a JMAP server.

So, how strong is the consensus around .unreadThreads? I fully understand
why it’s current behavior would be desirable, so I’m going to jump to the
conclusion that it might be worthwhile considering the addition of a new
Mailbox property,  “unreadEmailsCollapsingThreads", or
“unreadCollapsedThreads”, to support a Gmail-like unread badge.

Thoughts?

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 07 Aug 2018 19:52:34 -0400

On Wed, 8 Aug 2018, at 7:08 AM, Neil Jhaveri wrote:
> For comparison, Gmail.com calculates unread thread counts only based off messages that are unread in the mailbox.

Oh, interesting. The unreadThreads definition was intended to give a count that matched the number of threads the user sees as unread if they open that mailbox. Is this not true in Gmail? I would have thought this would lead to user confusion (if there's ever a bug where the unread count in the sidebar doesn't exactly match the number of unread threads a user sees, we certainly get support tickets about it!).

> So, how strong is the consensus around .unreadThreads? I fully understand why it’s current behavior would be desirable, so I’m going to jump to the conclusion that it might be worthwhile considering the addition of a new Mailbox property,  “unreadEmailsCollapsingThreads", or “unreadCollapsedThreads”, to support a Gmail-like unread badge. 

Hmm. There are a few options I guess.
 1. We could make it server-defined, and say it must only be used to give a guideline to users about how many unread threads may be in the folder. This is a bit like how search text-matching semantics are deliberately undefined.
 2. We could define two properties.
 3. We could pick one and make the other one an extension.
 4. We could just leave it as is (but then it may be more likely servers will violate the spec for ease of reusing existing implementations).

I… don't know really. Thoughts, anyone?

Neil.

---

From: Neil Jhaveri <[email-masked]>
Date: Tue, 7 Aug 2018 19:12:22 -0700

Just to be extra sure, I did just verify... I had a thread with 4 messages,
2 in the Inbox, 2 in a separate label, and marked the 2 in a separate label
as unread. The Inbox shows the thread as unread, but the Inbox unread count
is 0.

I actually think all the common unread count strategies (unread messages,
unread messages collapsing threads, and unread threads) come with scenarios
under which they're a tiny confusing. To me, what's important is
consistency.

So that narrows it down to... either #1 (server-defined), or #2 (two
properties).

>From the perspective of the client I'm working on, #2 is nice because a
Gmail and a Fastmail JMAP account could both behave the same. But I'm more
than happy to live with the counts being server-defined, because I'd
probably have other behaviors like the "Archive" action also be different,
based on Gmail or not.

So the more I think about it, the more I lean towards letting the exact
behavior be server defined, and loosening the definition... unless somebody
also sees a need for the two counts.

On Tue, Aug 7, 2018 at 4:52 PM Neil Jenkins <[email-masked]> wrote:

> messages that are unread in the mailbox.
>
>
> Oh, interesting. The unreadThreads definition was intended to give a count
> that matched the number of threads the user sees as unread if they open
> that mailbox. Is this not true in Gmail? I would have thought this would
> lead to user confusion (if there's ever a bug where the unread count in the
> sidebar doesn't exactly match the number of unread threads a user sees, we
> certainly get support tickets about it!).
>
>    1. We could make it server-defined, and say it must only be used to
>    give a guideline to users about how many unread threads may be in the
>    folder. This is a bit like how search text-matching semantics are
>    deliberately undefined.
>    4. We could just leave it as is (but then it may be more likely
>    servers will violate the spec for ease of reusing existing implementations).
>
>
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 8 Aug 2018 21:04:41 +0200

"Server defined" is a nice way to let servers do what is easy and cheap 
for that particular architecture. But I worry that in the case of mail, 
its practical meaning is "servers may be incompatible with Gmail if 
they think the trouble is worth it", which implies that the mere 
statement needs more scrutiny.

Arnt

---

From: Neil Jenkins <[email-masked]>
Date: Fri, 17 Aug 2018 02:21:05 -0400

Server defined seems likely to be the way to go here. I propose the following text; please reply with any comments or concerns, and I'll update this next week:

----

*unreadThreads*: PositiveInt (server-set)

An indication of the number of "unread" threads in the mailbox. This may be presented by the client as a badge or marker associated with the mailbox.

For compatibility with existing implementations, the way "unread threads" is determined is not mandated in this document. The simplest solution to implement is simply the number of threads where at least one email in the thread is both in this mailbox and has neither the $seen nor $draft keywords.

However, a quality implementation will make return the number of unread items the user would see if they opened that mailbox. A thread is shown as unread if it contains any unread messages that will be displayed when the thread is opened. Therefore unreadThreads should be the number of threads where at least one email in the thread has neither the $seen nor the $draft keyword AND at least one email in the thread is in this mailbox. Note, the unread email does not need to be the one in this mailbox. In addition, the Trash mailbox (that is a mailbox whose role is trash) is treated specially:

 1. Emails that are *only* in the Trash (and no other mailbox) are ignored when calculating the unreadThreads count of other mailboxes.
 2. Emails that are *not* in the Trash are ignored when calculating the unreadThreads count for the Trash mailbox.

The result of this is that emails in the Trash are treated as though they are in a separate thread for the purposes of unread counts. It is expected that clients will hide emails in the Trash when viewing a thread in another mailbox and vice versa. This allows you to delete a single email to the Trash out of a thread.

So for example, suppose you have an account where the entire contents is a single thread with 2 emails: an unread email in the Trash and a read email in the Inbox. The unreadThreads count would be 1 for the Trash and 0 for the Inbox.