Original text:
This information is aggregated in a "PublicGroupState" object as follows: <del> "struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 epoch; opaque tree_hash<0..255>; opaque interim_transcript_hash<0..255>; Extension extensions<0..2^32-1>; HPKEPublicKey external_pub; } PublicGroupState; " </del> Note that the "tree_hash" field is used the same way as in the Welcome message.  The full tree can be included via the "ratchet_tree" extension ratchet-tree-extension. <del> The information above are not deemed public data in general, but applications can choose to make them available to new members in order to allow External Commits. </del>  External Commits work like regular Commits, with a few differences:

Reviewer comments:
The unsigned PublicGroupState created by leads to an attack on the new joiner. The sender of a GroupPublicState can associate any HPKE it wants with the group, and thus learn the without being a member of the group. (The UpdatePath and the resulting partly defend against this attack, though they are subverted if the attacker has compromised any single key used in the Update Path.) To guard against this attack, this PR adds a signature over the HPKE public key in the PublicGroupState.
In light of the feedback on the mailing list from NAME re: deniability, I have upgraded this PR to sign the whole PublicGroupState.
Outstanding issue: One detail that is not fully covered by is the strategy new joiners should apply to determine who the latest committer is and make sure that both the and the last Commit are signed by the same member.
The last node to send an UpdatePath is the last one to set the root. So you can follow parent_hash to find which leaf it is. But like I said on the IETF meeting call, I don't think we should actually require that PublicGroupState be signed by the last updater. There are possible operational/sync issues if the PublicGroupState isn't fate-shared with the Commit, but that's a practical issue, not a security issue. And in any case, it's not a breaking change, so we can fix it post-draft-11 if we decide we need to.
Please fix the link on the repo page to display diffs between the current editor's draft and the WG draft. Now, it should PRs comparing back to the -00 version.
NAME Any change you could have a look at this when you have some time ? : )
Yeah, I'm gonna fix the CI and I can take a look at this as well. I tried to get it done before the interim but, well, excuses excuses
Ahah... ;) No problem!! Thanks !
NAME -- last call on this, or i'm just going to close it
Sorry. As you will have guessed, this fell through the cracks. I'll try this week to fix it out and close it out if I don't get to it this weekend :/

Revised text:
This information is aggregated in a "PublicGroupState" object as follows:  Note that the "tree_hash" field is used the same way as in the Welcome message.  The full tree can be included via the "ratchet_tree" extension ratchet-tree-extension.  <ins> The signature MUST verify using the public key taken from the credential in the leaf node at position "signer_index".  The signature covers the following structure, comprising all the fields in the PublicGroupState above "signer_index": This signature authenticates the HPKE public key, so that the joiner knows that the public key was provided by a member of the group.  The fields that are not signed are included in the key schedule via the GroupContext object.  If the joiner is provided an inaccurate data for these fields, then its external Commit will have an incorrect "confirmation_tag" and thus be rejected. The information in a PublicGroupState is not deemed public in general, but applications can choose to make it available to new members in order to allow External Commits. </ins> External Commits work like regular Commits, with a few differences: