Original text:
ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define <del> recursively, starting with the leaves.  The hash of a leaf node is the hash of a "LeafNodeHashInput" object: </del>  <del> The content within the leaf of a ratchet tree is composed of a "ClientInitKey" when the leaf is populated.  The "info" field is equal to the null optional value when the leaf is blank (i.e., no member occupies that leaf). </del>  <del> The intermediate nodes contain less information, the hash of a parent node (including the root) is the hash of a "ParentNodeHashInput" struct: </del>  The "left_hash" and "right_hash" fields hold the hashes of the node's <del> left and right children, respectively.  The "public_key" field holds the hash of the public key stored at this node, represented as an "optional<HPKEPublicKey>" object, which is null if and only if the node is blank. </del>  7.4.

Reviewer comments:
It seems like there's a major thing missing here, namely how the sender of a Commit transmits the new node signatures to the other members of the group. We need something like that before this lands. The most obvious approach would be to add a field to DirectPathNode, as you have with RatchetNode.
It would also be handy to include in the intermediate node an indication of which leaf signed it. Otherwise you have to do "trial verifications" (cf. trial decryption), which is expensive.
Was this addressed? it's mentioned that the signature should be transmitted in "Synchronizing Views of the Tree" but there's no signature in the transmitted DirectPathNode
NAME changes the strategy for signing the tree, everything should be sorted out there.
Here's the Weekly Digest for : - - Last week 8 issues were created. Of these, 0 issues have been closed and 8 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

Revised text:
ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define  <ins> recursively, starting with the leaves. While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group agreement.  Siganatures are especially important in the case of newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement. </ins>  <ins> Elements of the ratchet tree are called "RatchetNode" objects and contain optionally a "ClientInitKey" when at the leaves or an optional "ParentNode" above. </ins>  <ins> When computing the hash of a parent node AB the "ParentNodeHash" structure is used: </ins> The "left_hash" and "right_hash" fields hold the hashes of the node's  <ins> left (A) and right (B) children, respectively.  The signature within the "ParentNode" is computed over the its prefix within the serialized "ParentNodeHash" struct to cover all information about the sub-tree.  The "committer_index" is required for a member to determine the signing key needed to perform the signature verification. To compute the hash of a leaf node is the hash of a "LeafNodeHash" object: Note that unlike a ParentNode, a ClientInitKey already contains a signature. </ins> 7.4.