/_matrix/client/r0/rooms/{roomId}/joined_members shouldn't exist.

[jevolk]

Inspired by matrix-org/matrix-spec-proposals#734 and introduced sneaked in by matrix-org/matrix-spec-proposals#999 and canonized in the r0.3.0 release of the specification under 6.3.5: the endpoint:

GET /_matrix/client/r0/rooms/{roomId}/joined_members

should instead be a query parameter to 6.3.4:

GET /_matrix/client/r0/rooms/{roomId}/members

taking the exact form of:

GET /_matrix/client/r0/rooms/{roomId}/members?membership=join

Consider these significant defects:

1. This endpoint has no potential to support other membership states. It is arguably just as useful, if not more useful to efficiently request a room's ban list as it is to request the join list. With this direction, entirely new endpoints have to be created for every membership state.

2. The content returned from this endpoint has a radically different format from the content returned from the /members endpoint. The latter returns an array of events. This endpoint returns a map of mxid's to some event content fields. Intuitively, this endpoint should return an array of events where the membership state is join. Standard filters can be used to slim down such events for efficiency at the discretion of the client.

3. "joined" is not a membership state. The endpoint along with the root object returned in the content is named "joined" -- this is correct english, but technically useless. Computers don't convert tense. Though I suppose to be consistent we could continue in this direction with /leaved_members

[richvdh]

the different response format was a deliberate choice, to reduce load on the server, iirc.

I can't disagree with any of this, though.

[Half-Shot]

Yes this does seem kind of rushed. And actually now I think about it I could have done with an invited list/banned list/left list for bridges :(