Code change:
clients using some identifier.  MLS clients have a few types of identifiers, with different operational properties. <del> The Credentials presented by the clients in a group authenticate application-level identifiers for the clients.  These identifiers may not uniquely identify clients.  For example, if a user has multiple devices that are all present in an MLS group, then those devices' clients could all present the user's application-layer identifiers. </del> Internally to the protocol, group members are uniquely identified by <del> their leaves, expressed as LeafNodeRef objects.  These identifiers are unstable: They change whenever the member sends a Commit, or whenever an Update proposal from the member is committed. MLS provides two unique client identifiers that are stable across epochs: </del> <ins> their leaf index.  However, a leaf index is only valid for referring to members in a given epoch.  The same leaf index may represent a different member, or no member at all, in a subsequent epoch. </ins> <del> The index of a client among the leaves of the tree The "epoch_id" field in the key package The application may also provide application-specific unique identifiers in the "extensions" field of KeyPackage or LeafNode </del> <ins> The Credentials presented by the clients in a group authenticate application-level identifiers for the clients.  However, these identifiers may not uniquely identify clients.  For example, if a user has multiple devices that are all present in an MLS group, then those devices' clients could all present the user's application-layer identifiers. If needed, applications may add application-specific unique identifiers to the "extensions" field of KeyPackage or LeafNode </ins> objects. 7.

Related discussion:
text: This seems to be a layer of indirection that doesn't add any value to implementation.
The Credentials section claims there is an epoch id field in key packages. I don't think that actually exists. My apologies if this is a duplicate issue.
Addressed in but may need to be pulled out depending on the fate of that PR
contains all of the Proposals that were previously sent within the same epoch. This seems unnecessary, since all members should have them anyway. The list of in the actual message should be enough for members to parse and validate a message. We should discuss if we can de-duplicate this, since the list of Proposals might be quite long.
The current definition of is as follows; Maybe this issue is obsolete?
Seems it is now obsolete indeed.
I don't have a strong opinion on this question, but this change seems sensible to me. The use of LeafNodeRef requires either (a) a linear scan through the tree, which is time-expensive in large trees, or (b) keeping an index that maps LeafNodeRef values to indices, which is storage-intensive in large trees. IIRC, the change to LeafNodeRef was made in the context of NAME work to make the tree description less tied to the array representation. In general, that is the right thing to do, and it's good that we did it. But we still have leaf indices anyway, for . Since we still have the concept, we might as well use it where it makes sense. And it certainly seems to me like and make sense, since they are internal to the protocol. In case folks are worried about the application-facing API -- MLS stacks can certainly be more intelligent, e.g., exposing or or . But they can do that regardless of this PR.