Remove essentially all uses of "tree".

[ekr]

In Eric Vyncke's DISCUSS he correctly notes that LeafNode is used without being defined. I fixed that by just removing the term but more generally the problem is the use of "tree" without it being defined. Obviously the tree is an important concept but that's really a matter for mls-protocol not mls-architecture which is just concerned with group state as an abstract structure.

This change removes essentially all uses of the term tree except for:

• In the final security considerations section where I think it's OK in context.

• In this sentence

  "A maximum number of steps that clients will move a secret tree ratchet forward in response to a single message before rejecting it."

I'm pretty sure that this can be reworded but I wasn't quite sure the best way.

[rohan-wire]

I think these cases all refer to the ratchet_tree extension, as opposed to the ratchet tree generally. I suggest leaving these as is.

[rohan-wire]

Suggested change

	- If assisted joining is desired (meaning that the group state is not
	- If assisted joining is desired (meaning that the `ratchet_tree` extension is not

[rohan-wire]

Suggested change

	group state corresponding to a group.
	ratchet tree corresponding to a group.

[rohan-wire]

Suggested change

	compute the group state itself (because some proposals or commits are sent
	compute the group state itself, including the corresponding `ratchet_tree`
	object, (for example, because some proposals or commits are sent

[bifurcation]

I'm less offended by "ratchet tree" here and more by "assisted joining", which is not defined elsewhere. So instead of the point edit @ekr has proposed here, I would suggest rewriting the two "assisted join" bullets entirely, something like:

Instead of distributing group information to a new members entirely within a Welcome messages, an application may rely on servers to store public information about the group, such as group members' credentials and related public keys, and provide this information to new members. (In such a system, Welcome messages are still necessary to convey confidential information about the group.) Such an application will require mechanisms for new members to download the current information for a group, and for members to update the information as the group evolves.

[ekr]

I adopted Richard's suggestion here. @rohan-wire @bifurcation PTAL.

[rohan-wire]

I'm less offended by "ratchet tree" here and more by "assisted joining", which is not defined elsewhere. So instead of the point edit @ekr has proposed here, I would suggest rewriting the two "assisted join" bullets entirely, something like:

Instead of distributing group information to a new members entirely within a Welcome messages, an application may rely on servers to store public information about the group, such as group members' credentials and related public keys, and provide this information to new members. (In such a system, Welcome messages are still necessary to convey confidential information about the group.) Such an application will require mechanisms for new members to download the current information for a group, and for members to update the information as the group evolves.

Fair enough, but this is the section on Operational Considerations, which is essentially a checklist of policy knobs for people who implement and deploy MLS. By this point in the document, these people better know what an assisted join is or we are doing them a disservice.