mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 04:56:03 +03:00
[GH-ISSUE #10] Enhancement: threaded or chat view #8
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dumblob on GitHub (Jul 30, 2015).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/10
Are there any plans to support threaded or chat view of messages?
@jasonmunro commented on GitHub (Jul 30, 2015):
I would love to support that in the future. Many IMAP servers provide the THREAD extension to pre-sort message lists by thread, and Gmail's IMAP implementation provides thread ids that can be used to do something similar. In the past I have written purely client side thread support, and it's .. messy and slow when using standard IMAP commands - so when we get to this it will likely hinge on the IMAP servers support for the THREAD extension.
@dumblob commented on GitHub (Jul 30, 2015):
Great news (I'm particularly interested in IMAP, no POP3). Are there any blockers for such module?
@jasonmunro commented on GitHub (Jul 30, 2015):
No blockers really, just the time to write the code :) I used to have IMAP THREAD extension support in our IMAP client library, but when I refactored that library for use in this project I ripped it out. it was just really terrible :) (I can say that with conviction since I wrote it!)
The first place to start is to build support for sending THREAD commands and parsing their responses in the IMAP lib. From what I remember parsing a thread response is not unlike parsing a bodystructure response (nested data structure), except it's quite a bit simpler than the latter. From there it's just a matter of wiring it up to the UI and resolving a few minor issues around that. After that I think it would be neat to leverage any enhancements the Gmail protocol extensions provide.
@dumblob commented on GitHub (Jul 30, 2015):
Understood - same here :(
Is there any good and up-to-date reference emphasizing the differences to standard IMAP?
@jasonmunro commented on GitHub (Jul 30, 2015):
There is a nice summary here:
https://developers.google.com/gmail/imap_extensions
Our IMAP lib already has limited support for some of these protocol extensions (maybe all of them, I honestly don't recall exactly), but we are not acting on the additional information in any way yet.
@marclaporte commented on GitHub (Sep 3, 2019):
I wonder if adding support only for JMAP would make it easier?
https://github.com/jmapio/jmap/blob/master/spec/mail/thread.mdown
https://github.com/jmapio/jmap/blob/master/server-guide/jmap-server-guide.mdown#2-threads
In Cyrus "Conversations (Server-side threading with reduced protocol chatter for mobile or other high-latency clients)" is "Required for JMAP support" Source: https://github.com/cyrusimap/cyrus-imapd/blob/master/docsrc/imap/download/packagers.rst
Related: https://github.com/roundcube/roundcubemail/issues/499
@marclaporte commented on GitHub (Aug 1, 2022):
https://datatracker.ietf.org/doc/html/rfc5256
@marclaporte commented on GitHub (Sep 3, 2022):
https://en.wikipedia.org/wiki/Conversation_threading
@marclaporte commented on GitHub (Aug 23, 2023):
https://meta.discourse.org/t/introducing-chat-threads/270613
@marclaporte commented on GitHub (Sep 11, 2023):
https://www.jwz.org/doc/threading.html
@marclaporte commented on GitHub (Sep 11, 2023):
Sorting: "If the IMAP server supports the IMAP extension SORT (most mainstream servers do) enable this feature in SquirrelMail's configuration. In general, always enable this option if your server supports it since it's way faster than sorting in SquirrelMail, and may prevent problems for end users with very large mailboxes."
Threading: "SquirrelMail also allows using server-side threading if the IMAP server supports it. This option offers the end users to view the message list in a thread view"
Source: https://www.squirrelmail.org/docs/admin/admin-6.html#ss6.3
@marclaporte commented on GitHub (Sep 23, 2023):
This is the oldest still open issue, and currently number 3 by reactions:
https://github.com/cypht-org/cypht/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions
We are currently increasing our development capacity/velocity, so we'll focus on quick wins for a few more months, and then come back for some more tricky ones like this.
@marclaporte commented on GitHub (May 20, 2024):
For the record, it is now number 2 now that https://github.com/cypht-org/cypht/issues/180 is done.
https://github.com/cypht-org/cypht/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions
@marclaporte commented on GitHub (Nov 22, 2024):
Related: https://github.com/max-mapper/conversationThreading-js
@indridieinarsson commented on GitHub (Mar 18, 2025):
@marclaporte Do you think the message threading would be done on the server or in the browser?
And a detail : in the combined inbox, mails from the last X days are show, lets say last 7 days.
If we have a thread that starts with a mail from 30 days ago, and the most recent mail is from today, would we show the entire thread? Or show only those messages in the thread that are from the last 7 days? intuitively, the first alternative sounds better, but it breaks the "last X days" filter.
@marclaporte commented on GitHub (Mar 18, 2025):
@indridieinarsson You are scratching the surface on why this is complex!
@marclaporte commented on GitHub (Mar 18, 2025):
Now number 2!
https://github.com/cypht-org/cypht/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions
@indridieinarsson commented on GitHub (Mar 18, 2025):
Ok. Let's chat a bit, and try to get it to number 1 then :)
There is an extension to the IMAP protocol, that implements threading. A variant of that even prescribes the exact same algorithm you linked above (from jwz). This is implemented by e.g. dovecot, stalwart.
Google, on the other hand, decide not to implement this, but offer access the results of their own threading algorithm. Using this over imap seems like a bit of a pain (but less so than implementing threading from scratch).
In JMAP, threads seem to be first-class citizens.
Wouldn't it make sense to implement threading on the server-side. Then use the imap/jmap provided threading algorithms where available? Then have a fall-back implementation of the jwz algorithm for servers that don't provide threading themselves (that would be gmail and outlook at least).
@kroky commented on GitHub (Mar 19, 2025):
I agree - threading must be done server-side. If the mail server supports the extension, we should use it as that will be better in performance. If not, we can implement it on the PHP side with some smart IMAP queries. I think a thread from the last 30 days should include the mail you received in the last 30 days but since it is in a thread - we should show the entire (or partial) thread including that message as the thread is relevant here. We should also probably limit the thread depth to some extent, especially in the list view for performance and visual reasons. When you open a mail that is part of a thread, we have greater flexibility there and the entire thread could be shown.
@marclaporte commented on GitHub (Apr 25, 2025):
Reactions are a little similar: https://github.com/cypht-org/cypht/issues/1366