Clarify historical key sharing

[HarHarLinks]

See https://github.com/matrix-org/matrix-spec/pull/2399/files#r3560365639

We understand there is an introductory paragraph to the use case, but we think it is setting the rest of the section up for confusion given

• that there is no clear requirement level for historical key sharing in general stated (only different aspects about how to create the key bundles etc)
• how fuzzy the spec is in general towards proper RFC 2119 usage.

Our reading of the spec is that for some reason there is an exemption for rooms that are currently not using shareable history, but by default ("otherwise") shareable keys hence may not not [sic!] be shared, i.e. MUST be shared. We think stating that outright clarifies this requirement a lot.

Further the way the exemption was defined was hard to grasp for a group of us, hence an attempt of a slightly more verbose approach.

Finally the error codes for withholding keys were missing a reference to when to choose which one.

Pull Request Checklist

• Pull request includes a changelog file
• Pull request includes a sign off
• Pull request is classified as 'other changes'

Preview: https://pr2410--matrix-spec-previews.netlify.app

[HarHarLinks]

• normative text explaining m.blacklisted, m.unverified, m.unauthorised, m.unavailable, m.no_olm, m.history_not_shared
• rework the paragraph "Alice’s client MAY choose not to share ..."

[richvdh]

I'm not really sure this is a helpful way of thinking about things? When Charlie sends a message in a room and marks it as shareable, he may not even know who Bob is, and no computation seems to be required. I really don't think that Charlie is "precomputing" anything?

[Also, it's a long time since Bob was mentioned, so we need to reintroduce him here. Admittedly that's a problem to some extent with the existing text, but at least we have Alice inviting Bob in the next paragraph at the moment.]

I suggest removing this paragraph.

[HarHarLinks]

matrix-spec/content/client-server-api/modules/end_to_end_encryption.md

Lines 1564 to 1565 in bb623a5

	Only room keys which were marked as "shareable" by the creator of the
	encryption session should be shared with new users.

Would you agree this should instead say

 Only room keys which were marked as "shareable" by the creator of the 
 encryption session MUST be shared with new users. 

(or less normative must)

given that further down defines

matrix-spec/content/client-server-api/modules/end_to_end_encryption.md

Lines 1634 to 1635 in bb623a5

	containing the sessions she is aware of in the room. Alice MUST include
	only [shareable encryption sessions](#shareable-encryption-sessions) in the

[richvdh]

Only room keys which were marked as "shareable" by the creator of the encryption session MUST be shared with new users.

That materially changes the emphasis: it implies that keys not marked as shareable can (and indeed probably should) be shared, which is obviously not what we mean.

If you wanted to strengthen this, it would need to say:

Room keys which were not marked as "shareable" by the creator of the 
encryption session MUST NOT be shared with new users. 

... however, that's an odd thing to say before describing sharing keys in general.

I think the current text is adequate, given (as you note) it's described more formally later on.