Allow email registration when no IS

[dbkr]

Split from #10552

[anoadragon453]

@dbkr What do you think about having /capabilities show you basic information if you're not authed, and auth-specific information if you are authed?

More work, but might be better down the line, plus it'll work for anything that requires knowing whether the homeserver handles email itself, which may be more than endpoints using UIAA.

[dbkr]

Yeah, I think that seems fairly reasonable. Only downside I can think of is that it's not necessarily obvious that authing will give you a different result, but it's probably not a problem.

[anoadragon453]

True. I'm also trying to think about how we will represent this in the spec, as currently we only have Requires Auth: <bool>.

Perhaps we don't require authentication on GET /capabilities, but do require it on POST /capabilities? Does anything currently require auth on /capabilities?

Spec for ref: https://matrix.org/docs/spec/client_server/unstable#get-matrix-client-r0-capabilities

[dbkr]

ah yes, although we shouldn't make decisions about our API based on what can be represented in the doc. :p If we were going to split them I'd say make 2 endpoints with different names, but personally I think I'd go for requires auth: no, then just add a freetext comment for now saying if you auth, maybe you'll get more stuff.

[anoadragon453]

What do you think about:

• /capabilities/server - public capabilities of the server, no auth
• /capabilities/user - user auth required and scoped capabilities

where /capabilities just returns what /capabilities/user returns for backwards compatibility?

[dbkr]

where /capabilities just returns what /capabilities/user returns for backwards compatibility?

other way around?

otherwise, yeah, I could get on board with that

[anoadragon453]

/capabilities is currently authed, and /capabilities/user would be the authed one.

Ok, I'll write the MSC for it.

[dbkr]

oh, right, yes