Contact/calendar support for TMail

[chibenwa]

User story

Contact

WHEN I type an Email address when I send an email,
THEN I want auto completion suggestions

The current solution for this is to rely solely on the phone contacts and on a database on the mobile.

Limitations:

• Users of the same domain (colleagues) are not to be found
• Suggestions are not consistent accross device
• WebMail have to contact application and no long term storage hence no contact support for now.

We wish to add backend support for autocompletion including:

• A user contact base
• Auto-complete email of other users (of the same domain)

Calendar

WHEN I receive an Email about an event (invitation)
THEN I should have information about this event
AND I should be able to manage my attendance from my mails

Nowadays received emails adds events on your calendar. However TMail have so far no strong support for Calendars

Screenshot of OpenPaaS bluebar feature:

Objectives

A (web) mail application clearly needs some kind of integration with a calendar / contact app (we speak of trinity).

To provide such a trinity in TMail we would like:

• 1. No hard link to a calendar APP. Because
     • Sabre is slow, not industrialised and would be a blocker to Tmail adoption.
     • Sabre have too many dependencies: MongoDB, ESN, Sabre itself, redis, ES 6) which means it is expesive to run anyway
     • Longer term survival of ESN based technologies is unclear. We should thus avoid hard dependencies
• 2. Minimal features, webMail centered can be delivered with TMail being standalone.
     • Event details in emails
     • Contact auto-complete
• 3. Easy to sync (asynchronously) with ANY contact/calendar DB

Non goals: We do not wish to offer a strong support for contact/calendar management and to replace the contact/calendar team.

Technical solutions

Calendar

1. JMAP Event/parse should allow the TMail fronts to parse an ICS attachment into a structured JSON representing and event.

They should be able to use it to display all bluebar related data

2. EventAttendance storage (memory + API + contract). 3. We also provide a Cassandra implementation of this.

This will be queried by JMAP to know the attendance status of an event.

3. EventAttendance/get + EventAttendance/set should allow one to manage its event attendance over JMAP

4. AMQP synchronisation

• Given an event created/managed in a third party software my attendance is up to date in TMail
• Given an attendance updated in TMail the attendance is updated in the third party software.

To achieve this TMail with receive/send specific AMQP messages.

Contact

1. Implement an EmailContactAutoCompletionEngine (memory and ElasticSearch)

It will allow storing email addresses of a contact of the user.

Given I auto complete bte it will search %bte%.

Use NGrams in ElasticSearch to implement this.

2. Implement a mailet to populate EmailContactAutoCompletionEngine

Recipients are added to the contact base of the sender.

3. Implement EmailContact/query

This can be used by mobile apps/web mail to auto-complete results (can be used by mobile apps to provide more results.

4. AMQP sync

• When I adda contact in third party APP, my auto-completion DB in TMail is updated.

We will receive an AMQP message telling us this, and we need to update our auto-complete DB accordingly.

5. User auto-complete.

When I add a user in the combined user repository, Then is gets added to a domain auto completion DB (similar to 1.). Domain users should be included in EmailContact/query(3.)

[vttranlina]

Will we still implement bloomfilter before indexing?

[chibenwa]

Will we still implement bloomfilter before indexing?

No it have a lot of downsides that may lead to corectness issues.

IMO we can imagine doing a get before indexing to avoid poluting ElasticSearch index...