| ## Data model overview |
| |
| ### Accounts |
| <aside class="warning"> |
| Not implemented |
| </aside> |
| |
| All data belongs to an account. An account may provide access to mail, contacts and/or calendars. Most operations are isolated to a single account; there are a few explicit operations to copy data between them. A single login may provide access to multiple accounts, for example if another user is sharing data with the user. |
| |
| ### Ids |
| <aside class="notice"> |
| Work in progress. Unique message id is generated by concatenate the username, the mailboxId and the uid. |
| </aside> |
| |
| All ids for messages, contacts, etc. are assigned by the server and are immutable. They MUST be unique among all records of the **same type** within the **same account**. Ids may clash across accounts, or for two records of different types within the same account. |
| |
| ### Mail |
| |
| As for all data types, each message has a unique, immutable id. This id does not change if the message changes mailboxes. A mailbox is a named, arbitrary set of emails. For compatibility with IMAP, a message MUST always belong to at least one mailbox at any time. |
| |
| Each message has 4 mutable boolean "flags" stored with it, each with a direct |
| equivalent in IMAP. In JMAP these flags are called: |
| |
| * **isUnread**: Has the email not yet been read? |
| * **isFlagged**: Has the email been flagged (starred, or pinned)? |
| * **isDraft**: Is the email a draft? |
| * **isAnswered**: Has the email been answered (replied to)? |
| |
| Messages are **immutable** other than these 4 flags and the set of mailboxes to which it belongs. To change anything else, the message must be deleted and a new one created (which will get a different id). |
| |
| Related messages are grouped into threads. When getting a message list you can collapse threads, which means the thread is only returned **once**, at the position of the first message in the thread in the non-collapsed list (given the sort order). |
| |
| ### Contacts |
| |
| The contacts API is designed to be compatible with existing CardDAV systems. Each contact must have a unique, immutable id. A contact can be assigned to contact groups in a many-to-many relationship. A group is simply a named set of contacts. Contacts are completely mutable. |
| |
| ### Calendars |
| |
| The calendars API is designed to be compatible with existing CalDAV systems. Each event must have a unique, immutable id. An event must belong to a single calendar. Events are completely mutable. |
