Summarize email thread

[ChristophWurst]

Is your feature request related to a problem? Please describe.

As a user I receive long email threads and I want to efficiently get the gist of them without reading the details.

Describe the solution you'd like

Show a text box below (long) threads with a few sentences of summary of the messages above.

A reference concept can be seen at https://www.youtube.com/watch?v=6DaJVZBXETE&t=25s.

Implementation

• Add API to summarize text server#38578 (to be done by the Nextcloud integration team)
• Requires mockup and interaction specs from designers
  • Where to render the text
  • Starting at how many messages in a thread do we summarize? 1? 2?
• MVP
  • Make it work with integration_openai mainly because that is fast
  • Process summaries on demand when the user opens the thread (in a web request, no background processing)
  • Fetch thread message bodies in a service inside the Mail app and send the data for processing to https://docs.nextcloud.com/server/latest/developer_manual/digging_deeper/text_processing.html
• Cache processed threads
• Document Mail summary feature documentation#10917

An API will be provided to which we can send text and retrieve a summary. Therefore, the Mail app has to be changed to collect a thread's message texts, have the text summarized and show the results in the UI.

Sync vs async processing

If the summary should show instantly, when loading the thread, the processing has to happen in the background and the result persisted with the thread data.
If the summary is generated async, the data can be processed on demand. Depending on the performance of the AI there can be a significant delay.

Opt-out

There will be people who don't want this feature. We should allow them to turn off the feature.

Describe alternatives you've considered

No response

Additional context

No response

[ChristophWurst]

Backend skills only required if the summary API is a PHP API. Then we need a small controller to invoke the API. If the API is exposed via OCS a frontender can query results directly.

[ChristophWurst]

The original idea was to do the processing in an AJAX request on-demand when the thread is loaded by the user. With the insights from nextcloud/server#38578 (comment) we'll have to remodel the architecture. It's not reasonable to process the summary on-demand.

The mail app will continue to synchronize mailboxes in the background like it does now. As the last step of this process, threads are (re)built. We have to add logic to detect when threads are new or changed. Then we have to fire an async text processing task to build the summary and register a listener to process/store the result. The result can go into something like a oc_threads table.

If a thread changes, the previous summary has to be discarded immediately so we don't show an outdated summary to the user if they open the thread earlier than the finished background task.

Stocking thread summaries sounds expensive, so I'm thinking of limiting the feature to threads of x messages. E.g. only start to summarize if there are three or more messages.

@marcoambrosini also raised that if you have an organizational instance with emails sent between a group of people, the same summary might be processed n times. It's to be evaluated if an optimization is possible.