* Make the purpose of the `auth` key in /register requests explicit, and say
that it should be empty at first.
* Restructure the UA-auth section a bit.
* In the UA-auth section, say that clients should submit no `auth` to start
with, and add 'Stage 0' representing this to the example.
* s/{stage,login} type/authentication type/ in the UA-auth section. Seems
clearer to me.
* Try to distinguish the example responses from the example requests by giving
an HTTP header.
* make it clearer which fields go in which parts of the rule
* the example given appeared to be for a content rule, so use a content rule
consistently through the examples.
Fixes https://matrix.org/jira/browse/SPEC-429.
Synapse currently follows the specified ordering, but does *not* give the
specified error when the state is invalid (instead it creates the room anyway
but gives a 403 M_FORBIDDEN). Still, I don't think that should be a real
problem for any real clients, and nothing would break if we changed this in
synapse, so it might as well go in the spec anyway.
We're licensing hte spec under ASLv2. Add the LICENSE file, and add the
short-form to as much of the source as is practical right now (adding it to
json source is a massive pita).
It's a bit incongruous to have to read through the deprecated /initialSync to
get to the good stuff. Separate out intialSync so that we can move it later in
the spec.
* Use the terminology 'login type' everywhere instead of mixing up 'stage type'
and 'login type'
* Don't have a separate 'APIs using the User-Interactive Authentication
mechanism' section, because (a) it doesn't make much sense to organise the
APIs this way, and (b) it was a set of lies anyway.
* Move '/account/password' definition into registration.yaml so that register
and password can share a section in the spec; remove duplicate doc for
/password.
* Write some words on using 3pids for /login
Erik Johnston