Change Details

Schema: - `id`: this is field working as autoincrement, in queries we'll pass it as `NULL` and SQLite engine will automatically assign it to track messages order ([docs](https://www.sqlite.org/autoinc.html)) - `message_id`: message ID needed to later confirm to the other peer that message was processed/backed up - `sender_device_id`: messages sender - `plaintext`: decrypted messages - `status`: messages status to distinguish in what phase this messages is, it will be something like `received | processed | backup-done`

Schema: - `id`: this is a field working as autoincrement, in queries we'll pass it as `NULL`, and SQLite engine will automatically assign it to track messages order ([docs](https://www.sqlite.org/autoinc.html)) - `message_id`: message ID needed to later confirm to the other peer that the message was processed/backed up - `sender_device_id`: messages sender - `plaintext`: decrypted messages - `status`: messages status to distinguish in what phase this message is, it will be something like `received | processed | backup-done`

Schema: - `id`: this is a field working as autoincrementnt, in queries we'll pass it as `NULL`, in queries we'll pass it as `NULL` and SQLite engine will automatically assign it to track messages order ([docs](https://www.sqlite.org/autoinc.html)) - `message_id`: message ID needed to later confirm to the other peer that the message was processed/backed up - `sender_device_id`: messages sender - `plaintext`: decrypted messages - `status`: messages status to distinguish in what phase this messages is, it will be something like `received | processed | backup-done`