v2 login flow representation (SPEC-118)

[matrixbot]

Consider if a tree-only approach is going to be better than using string arrays.

Complete stages:
foo -> bar
  `--> baz

alice -> bob -> charlie

stages: [
  {
    type: "foo",
    stages: [
      { type: "bar" },
      { type: "baz" }
    ]
  },
  {
    type: "alice",
    stages: [
      {
        type: "bob",
        stages: [
          { type: "charlie" }
        ]
      }
    ]
  }
]

@​eternaleye for suggestion:

M-kegan: Well, if "next" can be a list, then the sensible thing IMO is to replace the 'stages' list with a 'stages' tree.
M-kegan: Basically, instead of info: [{type, stages}] where stages: [type], have info: [{type, stages}] where stages: info
M-kegan: And then the absence of 'stages' indicates bottoming out on the auth flow.
M-kegan: Plus, if the next key is also an info (for a subtree), then it can just be treated as recursion in clients.
M-kegan: Also, it being a tree would allow stuff like a client library pruning by the auth methods it supports before returning the info to its caller
M-kegan: I guess part of it is that I feel the different representations may be a source of implementation bugs (especially server-side)
M-kegan: Another benefit is that server-side implementations could actually represent the auth setup as a tree, and just have a serializer to generate the appropriate json

(Imported from https://matrix.org/jira/browse/SPEC-118)

(Reported by @kegsay)

[matrixbot]

Jira watchers: @kegsay

[matrixbot]

Links exported from Jira:

relates to https://github.com/matrix-org/matrix-doc/issues/578
relates to SYN-396