afaik MLS doesn't currently support deniability. This means you can have attack where a member of the group conversation can prove in retrospect that an encrypted message was sent by a given sender. This is a big deal if you want to be able to talk freely without being blackmailed - for instance, I might want to say something to a given user intended only for their eyes, and if they then take that info and show it to other people (e.g. to blackmail me), I want to be able to claim that they faked the screenshot or otherwise fabricated the message. I certainly don't want some sort of signature on the message undeniably tying it back to me.
Now, Double Ratchet (and Olm and Megolm in Matrix) provide cryptographic deniability by using MACs rather than signatures for integrity, meaning that any given message could have been faked by the other participant in the conversation (given they know the secret that would allow them to encrypt that message themselves).
However, it's worth noting that practically speaking, a malicious server admin could turn up with some snapshots of their DB or some server logs with the ciphertext in them and say "i can prove that that screenshot's not faked, because my server saw that encrypted message sent from that user". And so if the admin was trusted (i.e. not colluding with the blackmailer), that could be seen as sufficient evidence to break deniability, albeit not at a cryptographic level.
So, basically: deniability is subtle - it's not obvious that cryptographic deniability is always a big win, given one can often find non-cryptographic ways to sufficiently prove that a user sent a message. That said, if you don't have cryptographic deniability, then you can be sure that a malicious conversation participant equipped with a suitable client which has forensics mode enabled will be able to produce evidence that cryptographically proves that you indeed said a given sensitive statement, whether you like it or not.
Now, Double Ratchet (and Olm and Megolm in Matrix) provide cryptographic deniability by using MACs rather than signatures for integrity, meaning that any given message could have been faked by the other participant in the conversation (given they know the secret that would allow them to encrypt that message themselves).
However, it's worth noting that practically speaking, a malicious server admin could turn up with some snapshots of their DB or some server logs with the ciphertext in them and say "i can prove that that screenshot's not faked, because my server saw that encrypted message sent from that user". And so if the admin was trusted (i.e. not colluding with the blackmailer), that could be seen as sufficient evidence to break deniability, albeit not at a cryptographic level.
So, basically: deniability is subtle - it's not obvious that cryptographic deniability is always a big win, given one can often find non-cryptographic ways to sufficiently prove that a user sent a message. That said, if you don't have cryptographic deniability, then you can be sure that a malicious conversation participant equipped with a suitable client which has forensics mode enabled will be able to produce evidence that cryptographically proves that you indeed said a given sensitive statement, whether you like it or not.