# NEWMEMO #
## Device ID Collision Discussion ##
Currently there is a risk of device id collision. A device id must only be unique per account, so there may be collisions in group chats.
## OMEMO Opt-out ##
- A client should offer the user to disable OMEMO encryption on this device.
- This option must remove the devices ID from the device list.
- As soon as the user opted-out of OMEMO on one device, the client MUST no longer publish their ID to the device list.
- It may also make sense to disable OMEMO on a per-conversation basis. This could be done by sending a signed `<deactivate/>` element or something.
## OMEMO Device List Labels ##
Clients may add human readable lables to the device list. Those contain a description of the device.
<device id='12345' label='converse.js Linux 07.03.2020'/>
<device id='42069' label='gajim.naksjdnkjnasd123'/>
## One Time PreKey Server Component ##
Clients currently upload ~100 prekeys in the bundle to the server.
When starting a conversations, the sending client fetches the whole bundle from the server and selects one key randomly.
Signal however uses a server component that selects the prekey for the device and deletes if afterwards. This saves bandwith and prevents collisions.
An OMEMO PreKey Server component would be nice to have but would probably be an optional feature which is prefered over the classic "bundle approach".
## Replace Protobuf? ##
No. Define own .proto file. Unique serialization is required.
## Details of initial X3DH handshake ##
It is not clear, how exactly libsignal currently handles sending multiple PreKeyMessages.
Alice -> Bob:
Wait, now it is clear.
The very first message Alice sends is `(PreKeyMessage1, WhisperMessage1)`
The first part of this message is the prekeymessage header, while the second part is a "normal" message header.
Until the recipient replies with a message, Alice sends `(PreKeyMessage1, WhisperMessage2), (PreKeyMessage1, WhisperMessage3)...`
## SCE ##
rpad RECOMMENDED! (at least, maybe even must)
The rules of how to chose the padding length shall be decided by the SCE spec.
SCE must come up with sensible config options
## AES128 vs AES256 ##
libsignal internally uses AES256 to encrypt the message key (which is currently 128bit), so upgrading the message key to 256bit as well makes sense and sounds *click* nice!
## Handle missing messages in UI? ##
Ratchet counter enable detection of missing messages. Do we need to act on this?
# Responsibilities!!!! #
* [Threat Model](https://hackmd.syndace.com/jG00qKF0SUy_AKUlXJcblQ#)