## Data model overview

### Accounts

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

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.