* Everyone should explicit-ack this message ASAP''m'' as soon as they receive it from the server.** This message should ack may also bundle any cryptographic material needed for other members to agree on a key or keys that exclude ''u''. For example, in the SenderKeys scenario, this would contain the next-sender-key, to be used after u leaves, encrypted to everyone except ''u. This ensures old members can't read new messages even if they eavesdrop'.** (We could probably do something similar for group keys.)* When this message ''m'' is fully-acked, ''u gains '' reaches consistency for all previous messages up to ''m'', and may leave.** Other messages should be probably Messages that others send to ''u'' that are echoed back after ''m'', will not be discarded - acked by ''u ''.** ''u'' won't have a chance to verify their reach consistencyfor these messages, even if ''u'' receives them.** Others won't have a chance to check that ''u'' read them, though they may be able to check that everyone else did. But ''u'' may still read them in theory, since they were encrypted to ''u''.** In either case, communicating this meaning to the user, should be already covered by the same UI as for case (a). In the first case, ''u'' may shortcut the timeout and just issue the warning straight away, or alternatively not display those messages to the user at all.