This would also slightly reduce the possibility of collision since the messages would only be threatened to collide with messages on the same depth. Drawbacks I can think of are:

1. Your message id is now dependent on the sorting scheme of the messagebox. In the future we may want 2 messagebox indexes, one for newest-oldest another for oldest-newest. Not terrible as we could just arbitrarily pick the newest-oldest threadkey for the key all the time.

2. Depending on if we switch to using the constructed messageId for message access in the REST APIs, the reference gets a bit longer and uglier (e.g., you now have this pipe thing at the end in the ids in your "permlink" reference to a message `/content/<contentId>/messages/<messageBoxId>#<threadKey>`) . If that discussion goes toward using compound key as separate parts, then you would still have something ugly like this for a "permlink": `/content/<contentId>/messages/<threadKey>`