Change:
unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. <del> Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. </del> <ins> Decide whether to populate the "path" field: If the "path" field is required based on the proposals that are in the commit (see above), then it MUST be populated.  Otherwise, the sender MAY omit the "path" field at its discretion. If populating the "path" field: Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. </ins> <del> Assign this DirectPath to the "path" fields in the Commit. </del> <ins> Assign this DirectPath to the "path" field in the Commit. </ins> Apply the DirectPath to the tree, as described in synchronizing-views-of-the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node. <ins> If not populating the "path" field: Set the "path" field in the Commit to the null optional.  Define "commit_secret" as the all- zero vector of the same length as a "path_secret" value would be. </ins> Generate a new KeyPackage for the Committer's own leaf, with a "parent_hash" extension.  Store it in the ratchet tree and assign it to the "key_package" field in the Commit object.

Discussion:
When we converted to the Proposal/Commit scheme, one of the consequences was that Adds became O(N) instead of O(1), since they had to Committed and commits encrypt the committer's direct path to the remainder of the tree. This is ~log(N) in the nice case and ~N in the worst case. At the time, we noted that one could special-case Add-only Commits in the future and make the update to the direct path optional in that case. This PR implements that suggestion. The leaf KeyPackage for the Commit is moved into the DirectPath struct, and the whole DirectPath is made optional. The optional value MUST be provided for: A Commit committing an update or remove A "just update my path" Commit covering no proposals
So we do go forward one epoch, but with an all-zero commit secret. Do I understand that correctly?
NAME That's correct. The idea is that you don't need to send the current group any additional entropy, you just need them to hash forward. Note that this could change the FS/PCS guarantees available. But I don't think we ever proposed that Add would cause any FS/PCS changes to the group, so maybe this doesn't matter.
Add should give FS guarantees in so far as that the new member shouldn't be able to decrypt old messages or derive old keys. But I think ratcheting forward should do the trick. We should note, though, that this breaks the (implicit) assumption that a commit always introduces fresh key material to the group. As far as I can see, that's not breaking anything right now, but we should keep it in mind.
Note: The latest commit fixes a gap that was discovered in .
See the flexibility question.