Password complexity error codes shouldn't be in the Matrix namespace

[turt2live]

synapse/synapse/api/errors.py

Lines 69 to 75 in e550ab1

	PASSWORD_TOO_SHORT = "M_PASSWORD_TOO_SHORT"
	PASSWORD_NO_DIGIT = "M_PASSWORD_NO_DIGIT"
	PASSWORD_NO_UPPERCASE = "M_PASSWORD_NO_UPPERCASE"
	PASSWORD_NO_LOWERCASE = "M_PASSWORD_NO_LOWERCASE"
	PASSWORD_NO_SYMBOL = "M_PASSWORD_NO_SYMBOL"
	PASSWORD_IN_DICTIONARY = "M_PASSWORD_IN_DICTIONARY"
	WEAK_PASSWORD = "M_WEAK_PASSWORD"

These are unspecified identifiers and thus are subject to the unstable namespacing rules.

[babolivier]

For context this comes from matrix-org/matrix-spec-proposals#2000 which predates unstable prefixes (at that time using M_ or m. namespaces was how you'd implement an MSC) so at this point I'm not sure it's fair to say it's a compliance issue - if so then we should also move away from identifiers such as m.relates_to and such since they're also unspecified and thus subject to the unstable namespacing rules.

[turt2live]

(m.relates_to is in the spec, but much of aggregations isn't: they're a somewhat different beast, but yes: we shouldn't have used m.* for that either)

[babolivier]

Ah sorry I missed that m.relates_to had made it to the spec, then correct my comment with something like m.reference.

I don't think the issue is whether we should or shouldn't have used the namespace for it; the issue is that then the rule was one thing and now it's another thing, and my understanding was that the compliant thing to do was to only consider unstable namespacing rules when dealing with rules from after this change. Otherwise it means all of the MSCs that are still open from before then are now invalid, with, for some, close to no way to make them valid.