This is going to be painful to represent due to how the push API allows
mixed types (strings or objects) and mixed top-level keys ("content" rule kind
allowing "pattern" as a top-level key). We may wish to re-visit the design
of this API for v2.
Also display "required" text on required JSON body request params. Also
increase the size of the request param column to support longer param names
present in the pushers API.
"joined/invited/archived".
Rename the room_map to rooms and remove the grouping indirection. When we
want groups then we can add them under a separate key, either at the
top-level or as part of the events themselves.
invite. This is kept separate from the actual state for the room as
it may be derived from an incomplete, unverified copy of the state
that was bundled with an invite event received over federation.
Divide the rooms into separate groups in preparation for adding tag
support.
Further subdivide the rooms into "joined/invited/archived" based the
membership of the user in the room because that membership affects what
events the user can view from the room. E.g only users that are joined
to a room may see the ephemeral events for the room.
Edit content-repo.yaml to include examples and headers.
Restructure content module to conform to the module template.
Adjust the HTTP API template to give 1 more char to the response
param to fit "Content-Disposition" correctly.
Edit the templating system to support displaying enums for
swagger APIs (before it was just JSON schema). Also add support
for introspecting headers from swagger. Finally, replace - with
_ when forming the {{ template_var }} else things whine.
Erik Johnston