As far as I can tell, these header files only encourage people to create
badly-formatted PRs.
Also we only have one template so let's give it the default name.
Also, some other editorial improvements, including factoring out our two definitions of the same key encoding algorithm.
Co-authored-by: Travis Ralston <travisr@matrix.org>
This was commented prior to the
port to OpenAPI 3.1 for technical reasons (#1127).
Now we can use it just fine.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Previously, titles would appear that do not link to a subchema definition.
It would also mean that named subschemas would appear without being clearly referenced.
Now, the type clearly shows the nesting of objects
and subschema definitions should be clearly referenced.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Otherwise the version might change depending on the runner.
We just use the same version as other jobs.
This removes a GitHub warning.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Upgrade version of Hugo used to build the spec in CI
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Escape HTML manually in property-type partial
The behavior of `delimit` changed,
so Hugo doesn't recognize "safe" HTML passed to it anymore, so it escapes nested HTML links.
To fix that we escape the schema data manually
and consider the output of the partial as "safe".
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Makes it easier to use, like resolve-refs. It just needs to be called once.
Fixes an issue with m.call.* events not displaying the common fields
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Since we already have three of these, and I'm about to add a fourth, let's pull
it out to a common definition.
We could, of course, keep defining the grammar each time it's used, but
defining it in an appendix helps us be consistent for future API design.
The split was not clear between property-type and type-or-title,
so it was not obvious which partial should be called for recursion.
That resulted in an error where type-or-title was only called for objects and array items, even if it also resolves
arrays of types.
This makes the split clearer. property-type must be called for any schema,
and object-type-or-title is only called for object schemas.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Use the resolve-refs partial as soon as possible
Call it right after accessing the site.Data,
since it is recursing it will solve all references in the tree.
That way we don't need to wonder where to call it,
we trust the validators that the refs will be used in the right place.
* Enable strict $ref rule in OpenAPI validator
* Document use of $ref to compose examples
* Fix schema path in event-fields shortcode
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Fix `v` tag_name prefix sneaking into npm version
* Fix `yarn version` failing in CI due to no git global ident name
* Add changelog
* Rename 1765.misc to 1765.clarification
* Break out non-JSON request/response content types as tables
Currently we display this as a table like "image/png|image/jpeg" and description on a single line, but we're using a table. This breaks the join out to individual rows.
* changelog
It was not enabled before the docsy update and it messes with
the TOC highlighting during the transition.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Deprecate the `font` HTML tag
Rationale:
MSC4077 allows to deprecate HTML tags
that are deprecated in the WHATWG standard,
if they can be replaced by tags with the same feature.
`font` is deprecated and can be replaced by `span`
with the `data-mx-bg-color` and `data-mx-color` attributes.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add deprecation info box
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Spec for MSC3981
This writes up https://github.com/matrix-org/matrix-spec-proposals/pull/3981
Hopefully this is relatively straightforward, apart from having to add
the parameters and response field in all three places. I tried to factor
these out but it seems references just aren't supported in the right
places currently (see https://github.com/matrix-org/matrix-spec/pull/1745
for my efforts). Path parameters can't be optional, so it can't be done
that way either.
* Missed schemas
* newsfile
* Actually it clearly isn't going to support markdown, is it?
* grammar
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* grammar
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Clarity
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Clarity
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Typo
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* More clarity.
Note this is counter what the MSC actually proposed to add, but
I think it's clear that this is what it meant.
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* clarification around implementation requirement, and mention new label
* add changelog
* fix typo
* Fix typos
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Add missing 'in' in SSO specification
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
* Use standard changelog entry for typos
---------
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Convert m.call.candidates schema to YAML
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Clarify that sdpMid and sdpMLineIndex are not required in `m.call.candidates`
MSC2746, merged in v1.17,
introduced the end-of-candidates candidate,
where only the `candidate` property is set to an empty string.
Besides, the [WebRTC specification](https://www.w3.org/TR/webrtc/)
says that only one of those fields is required in a normal candidate.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Link to the "End-of-candidates" section, and clarify what "empty" means
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Disambiguate uses of PublicRoomsChunk
Make sure that different objects don't share the same title.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Clarify that extra fields of space hierarchy children are not required
There is no `children_state` field,
the `room_type` is only set for spaces
and the description of `allowed_room_ids` says that the field can be omitted.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Use `body` field as media caption
As per MSC2530.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Use `s` HTML tag in example
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Move changed-in annotation
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* clarify otk and fallback key types in examples
- remove unsigned curve25519 keys from examples because we don't use those for
otks and fallback keys
- add missing `device_unused_fallback_key_types` property, which is required
* add changelog
* Clarify that the key backup MAC is implemented incorrectly
Due to a bug in libolm, all implementations of the
m.megolm_backup.v1.curve25519-aes-sha2 key backup algorithm incorrectly
pass an empty string through HMAC-SHA-256 to generate the `mac` property
of the `session_data`.
It was intended for the entire raw encrypted data to be passed through
HMAC-SHA-256, but the issue was caught too late in the process, and thus
we are stuck with this until a new key backup algorithm is introduced.
This commit clarifies the real-world behavior of all current
implementations.
Signed-off-by: Sumner Evans <sumner@beeper.com>
* Make clear the thread root is not in the thread
Signed-off-by: Andy Balaam <andy.balaam@matrix.org>
* Changlog entry for thread PR 1677 - thread roots not in thread
* Fix typo
* Add formatting for code values.
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Reword main timeline ID paragraph
* Use close to the original wording for the 'recurse' part of the 'in the thread' definition
* Remove note about thread roots being displayed in a thread
* Define the thread root
---------
Signed-off-by: Andy Balaam <andy.balaam@matrix.org>
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
This is already mentioned for /user/devices, but is not mentioned for /query/profile, /user/keys/claim, or /user/keys/query.
See GHSA-mp92-3jfm-3575 for an issue found with this in Synapse.
* Upgrade most github actions
Gets rid of warning in CI complaining about those actions
using node 12.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Upgrade node version used to run scripts
Use the latest LTS
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
... and other improvements
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update server-server-api.md
I have updated the list of Resolving server names in step 3 from unordered list to ordered list. Because we care about its order
* Create 1567.clarification
* Delete 1567.clarification
* Create 1623.clarification
* Update 1623.clarification
* Remove duplicate words.
* Add information on room version 11.
* Note some event changes.
* Newsfragment
* Fix-up event schema.
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Fix 'new in this version'.
* Clarify creator field.
* Fix-up event format & examples.
* Move the Redactions section to the client section.
* Reference the sender instead of the creator.
* More links
* Even more links.
* Fix order of headers.
* Fix typos.
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Clarify description of creator.
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Clean-up intro paragraphs for redactions.
* Clean-up examples and language.
* Review comments.
* FIx-up markup tags.
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Add MSC2249 support
* changelog
* Add a line on verification
* Changes based on review feedback
* Apply suggestions from code review
Co-authored-by: Travis Ralston <travpc@gmail.com>
* move tags field to the bottom of report_content.yaml
* fix duplicated content
now how did that happen
* fix up the 404 response schema
it wasn't displaying correctly in the rendered spec otherwise
* remove erroneous schema reference
* 1.7 -> 1.8
Co-authored-by: Travis Ralston <travpc@gmail.com>
---------
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Andrew Morgan <andrew@amorgan.xyz>
* Specify our usage of ABNF for grammar
* Create 1582.clarification
* Update meta/documentation_style.rst
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Was previously using <a name="..."> elements which just
add another anchor rather than changing the existing one.
They also use a deprecated HTML attribute and in some cases
broke the header display.
Fixes#1572.
Signed-off-by: Midnight Veil <midnightveil@fea.st>
* Bump the version of jsonschema
OpenAPI 3.1 uses JSON Schema Draft 2020-12 so we need a version that
supports it.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Fix PR number
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add a spec release checklist issue template
because I'm tired of copy/paste
* Document a chunk of our release approach
This should probably go elsewhere, but here is fine for now as a SCT-referenced doc/content.
* changelog
* Brief clarifications
* Mark the appservice ping response duration_ms field as required
As intended in MSC2659.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Change version field to a string
And add the notes on how the version field works.
* Add spec requiring tracks to be within streams.
* Put streams spec in its own section
* Add 'invitee' field
* Add party_id
* Remember how JSON works
* Add m.call.select_answer
* Update examples
* Add select_answer to call flow example diagram
* Add m.call.reject
* Make party_id required in other events
* Add possible ways for client to handle an invite
* Convert hangup & reject events to YAML
So we can have a bulleted list in the description for the values
of 'reason'.
* Add new reason codes to hangup & reject
* Add m.call.negotiate
* Add other sections
* Revert changes to package lock
* Typos
* Fix type of other version fields, fix anchor.
* Add newsfragment
* Fix reason in hangup/reject
* Change tense
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Tense, typos & grammar
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Linkify
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Remove unnecessary parts from link
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Capitalise
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Fix hangup reasons
* Clarify who can answer
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Linkify
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Remove reference to 'this MSC'.
* Move common VoIP fields into a call event type.
* Move common voip events to the content, not the actual event
* Remove reason from reject event
I confused myself, but it's not in the MSC and it shouldn't be.
* Failure to YAML
* Fix number of room members allowed when sending voip events.
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Add 'added in' version
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Another added-in
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* Add missing comma
---------
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
Co-authored-by: Travis Ralston <travisr@matrix.org>
* Specify MSC3882: Using an existing session to log in another
MSC: https://github.com/matrix-org/matrix-spec-proposals/pull/3882
* Changelog entries
* Update data/api/client-server/login.yaml
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Link to endpoint
* Copy/paste `auth` dict definition
* Move get_token API to the correct version prefix (v1, not v3)
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Add `allow_redirect` query parameter to relevant media endpoints
* Add added in version flag to `allow_redirect` params
* Add 307/308 responses to media endpoints
* Add changelogs
* Remove the `dont_notify` and `coalesce` push rule actions.
Per MSC3987, these should both be considered no-ops.
* Remove obsolete dont_notify from default rules.
* Remove obsolete dont_notify from examples.
* "MXC URI" -> "`mxc://` URI"
We're a bit inconsistent with this currently, and IMHO "`mxc://` URI" is more
explicit.
* Update content/client-server-api/modules/content_repo.md
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
* more MXCs
---------
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
There was substantial confusion around this, but I've done some archaeology.
Basically, this was changed back in r0.5.0 by MSC1304 and matrix-org/synapse#3397. Before that, it was indeed the case that state_default was 0 if there was no m.room.power_levels event, but that was confusing and a source of security holes, so we changed it.
matrix-org/matrix-spec-proposals#1656 changed the spec, but apparently overlooked the text in the description.
Reverts: #1478.
Fixes: #861.
* Add information on MSC3758: event_property_is.
* Add information on MSC3966: event_property_contains.
* Add information on MSC3873 dotted-path escape rules.
* Newsfragment
* Update sync filter with ref to appendix.
* Escape example key.
* Fix typos.
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
* Fix links.
* Clarify the appendix a bit.
* Clarify support values.
* Add MSC3980 to changelog.
---------
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
* Mention that `state_default` can be zero by default.
* Changelog
* Update data/event-schemas/schema/m.room.power_levels.yaml
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
---------
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
I've done my best to remove the word "bundle", because I feel like it causes
more confusion than it provides. Instead I have favoured "aggregated child
events" which I think is clearer.
Some general clarification around these parts of the spec.
* `cross_signing_key.yaml`: the parameter documentation already restricts the number of properties
* `receipts.yaml`: use `maxProperties: 0` to say the object is empty (the comment is still there but is not really needed any more)
Signed-off-by: Alexey Rusakov <Kitsune.Ral@users.sf.net>
This strives to fix all remaining cases where additional attributes
(most often 'description' but not only) are provided next to $ref
by wrapping $ref in allOf; and also drops allOf in a couple of places
where $ref is the only element under it.
The syntax is incorrect and would require to use allOf
because a $ref can't have siblings.
However the only field not overwritten of that definition is room_id,
so we include it instead of the $ref
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Originally the tags used to be bold, followed by a colon and separated
into two columns in a table. This at least restores the table aspect,
which makes it clear, that font is not an attribute (and similar).
This seems to have gotten lost in the transition to the new design.
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
* replace "<content>" with "content"
This parameter that's part of the content-repo openapi spec causes generators to mess up
* added changelogs
* Update changelogs/internal/newsfragments/1370.clarification
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Change default room version from 9 to 10 in accordance with MSC3904
* Add changelog entry with assumed PR number.
* Fix missing comma in changelog.
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Travis Ralston <travpc@gmail.com>
If an object definition already has an example, we shouldn't try to extend that
definition by adding examples derived from the individual properties. Doing so
is confusing, and there is no way to inhibit it when it is not desired. It's
also not what the RapiDoc viewere does, so we end up with examples being
inconsistent.
The top-level `example` in `edu.yaml` was overriding the individual examples
for `edu_type`. Let's fix that by getting rid of the example in `edu.yaml`.
Fixes https://github.com/matrix-org/matrix-spec/issues/805
The OpenAPI 3 spec doesn't allow building examples by composition.
Either the whole example must be a reference, or it has to be included.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
I forgot to set the `items` on an array definition, and got an extremely
opaque error. Hopefully this will improve the lives of anyone who makes a
similar mistake in future.
Replace the current stack of hugo templates with a towncrier invocation. The main advantage of this is that it means that the "Changes since last release" section is consistent with the changelogs for the actual releases.
This also changes the release process so that the changelog is generated before tagging, which means that the thing tagged v1.5 is actually the v1.5 spec.
Fixes#908.
Stick a `definition-` on the front of the autogenerated anchors for definition
blocks.
This solves a problem where, for example,
https://spec.matrix.org/unstable/application-service-api/#registration could
refer to either the "Registration" section or the `Registration` definition
therein.
(These anchors are relatively recent: they were added in #1191.
This is based on the behavior of Synapse and Dendrite. Conduit's implementation is already non-compliant in regards to what was already defined in the spec.
Closes#645.
Related to #647 (probably closes it too, unless we want to be more explicit somewhere about what can be changed on default push rules).
Related PR in ruma that would allow to fix Conduit's implementation: ruma/ruma#1364
Signed-off-by: Kévin Commaille zecakeh@tedomum.fr
The link checker doesn't understand that we dynamically re-assign element IDs
at load time, so was failing for a few links that were technically valid
(though presumably still broken for any client not using JS).
Work around this by manually setting a few anchors, linking to other nearby
bits of text, or just changing heading titles.
* Spec reference relationships
MSC: https://github.com/matrix-org/matrix-spec-proposals/pull/3267
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Edits per code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Spec MSC3771: Threaded read receipts
Note: this builds on a (as of writing) non-existent "threading" section, which is part of a different commit.
* Spec MSC3773: Threaded notifications
* changelog
* Various clarifications per review
* Spec MSC3440: Threading (just the base)
Other threading MSCs to follow
* Spec MSC3856: Threads list API
* Spec MSC3715: Add`dir` to `/relations`
* changelog
* Apply suggestions from code review
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Update changelogs/client_server/newsfragments/1254.feature
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Convert `m.receipt.yaml` to traditional YAML
* Spec MSC2285 (private read receipts)
* Add some obvious copyright headers
* Add changelog entries
* Appease the linter
Apparently it hates it when you do this.
* Allow m.fully_read on /receipts
* Apply suggestions from code review
Co-authored-by: Matthew Hodgson <matthew@matrix.org>
Co-authored-by: Matthew Hodgson <matthew@matrix.org>
* Add CORP headers to media repo
MSC: https://github.com/matrix-org/matrix-spec-proposals/pull/3828
* Write weird CSS rules to make added-in work inline in the CS spec
Even though our content doesn't need 2 paragraphs, it's good to have the capability to render it in the future.
* Remove test paragraph
* Refine prose
* spelling is key
* Remove redundant call to resolve-allof
All of the callers to resolve-additional-types already call resolve-allof (or
if not, they should), so this is redundant.
* Update `resolve-additional-types` to take a dict
I want to add more params to this, so first make it take a dict.
* `render-object-table`: take a "title" rather than a "caption"
... which means we can use the result from resolve-additional-types directly.
* render-object-table: support adding an anchor to generated tables.
* resolve-additional-types: generate an id for each returned type
* render-event: pass an anchor_base into resolve-additional-types
This means that it will generate an anchor for each type, whihc will then be
passed into render-object-table and used as an `id` for the table.
* render-operation: pass an anchor_base into resolve-additional-types
* newsfiles
Folks who want to report a blank issue can still get at the form if they try hard enough, but in general everything should have a label to make triage easier.
* Fix typo in m.secret.request device event name
I don't think this is supposed to be plural according to the various SDKs
* Add changelog
* Update changelogs/client_server/newsfragments/1135.clarification
* Update changelogs/client_server/newsfragments/1135.clarification
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Clarify that /invite will respond with 200 if the user is already in the room
* Create 1084.clarification
* Update changelogs/client_server/newsfragments/1084.clarification
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Revert "Note a more efficient computation of the auth difference. (#1119)"
This reverts commit a707266e50.
* Changelog
* Delete 1132.misc
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Arrange a few titles
Before this change, PublicRoomsChunk in the spec text could be found in
two places (actually three but the third one is identical to the first
one), defining two (_mostly_ identical but) different schemas.
Ctrl-F'ing through the spec may confuse you with the "wrong" definition.
This commit gives distinct schemas distinct names; aside from
PublicRoomChunk, the same story happens with the derivative of
stripped_state.yaml used in space_hierarchy.yaml (it's not exactly
StrippedStateEvent either).
As for the removal of `PublicRoomsChunks` (plural) - this title is
unnecessary because the tooling would place rather self-explanatory
`[PublicRoomsChunk]` without it, whereas the plural title ends up with
no definition in the spec text.
* Add changelog
* keys.yml: fix one_time_keys object contents
The alternatives previously listed under two additionalProperties levels
are actually one _more_ level deeper; we still can't define them in
a formal way before moving to OpenAPI 3 but at least let's be honest
and say there's always a dict where there's always a dict. Also,
since the same data structure is used in three places now, at least
give it a name, and document the actual definition (once) separately
(not using it now because it's OpenAPI 3).
* Changelog
* openapi_extensions.md: fix typos and leftovers
dump-swagger had to substitute things in the past - these days it
just merges definitions.
* Changelog
In #1042 I incorrectly wrote that the conflicted state set is a set of
pairs (K, V). We later take the union of the conflicted state set and
the auth difference. The latter is a set of events (V) only.
Fix this by making the conflicted state set a set of events rather than
a set of pairs. That is, the conflicted state set is a a `Set[Event]`
instead of a `Set[((type, state key), event)]`.
* Commit to show changes to rich replies section
* Move rich replies to a module
* Add remainder of MSC2674
* Pivot away from MSC3440: Threads
* Add changelog entries so far
* Make a note for why we have aggregations/relations if nothing uses it
* Outright remove threads references
Apparently this breaks the table of contents
* Define MSC2675
* Define MSC3666
* Add note for rich replies?
* Update content/client-server-api/_index.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Clarify how ignoring works for aggregations.
* Try to clarify redactions a bit
* Clarify using parent/child language
* Add missing bits of MSC2675
* Add changelog for aggregations
* Appease the linters
* Update data/api/client-server/relations.yaml
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Try to clarify the return of /relations
* Fix required attribute
* Fix wording round 1
* Try to fix pagination
* Copy/paste the endpoint to make Open API happy
* Fix code block examples for rich replies
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Apply suggestions on all 3 endpoints
* Fix description of relationships API
* Fix warning about server-side aggregation/bundling
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Clarification on historical power level handling
* Revert "Clarification on historical power level handling"
This reverts commit f443b3d5a9.
* Clean up
* Let us try this again not using VS Code
* Markdown is full of mysteries
* Move stringy power levels to room versions
* Describe range
* Fix minor issues with previous room version stuff
* Copy/paste v9 into v10
* Describe deprecated formatting
* Paste unmodified auth rules from v8 into v10
* Move 9.1 to 9.3, add 9.1 and 9.2 for integer enforcement
* Add knock_restricted to v10 auth
* Misc cleanup and clarification for fragments
* Describe `knock_restricted` client changes
* Changelogs
* spelling
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Apply code review suggestions manually
* Fix v9 redactions
* Fix auth rules clarity issues
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Remove false integer requirements
Co-authored-by: Neil Alexander <neilalexander@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* room_type is not a required parameter in practice
In practice servers seem to mirror what the room create event does and
leave out the room_type when unset.
Signed-off-by: Nicolas Werner <n.werner@famedly.com>
* Add changelog
Signed-off-by: Nicolas Werner <n.werner@famedly.com>
* Also make room_type and allowed_room_ids optional in the openapi
They are optional according to the text, but the openapi marks them as
required instead.
Signed-off-by: Nicolas Werner <n.werner@famedly.com>
* Fix copy and paste error of newsfragment
Signed-off-by: Nicolas Werner <n.werner@famedly.com>
* fix: spaces hierarchy paramater types
- changed `limit` parameter type to integer
- changed `query` parameter type to integer
A floating number does not make any sense here. Also, at least Synapse
does not allow floating point numbers in here.
Signed-off-by: TheOneWithTheBraid <the-one@with-the-braid.cf>
* Update changelogs/client_server/newsfragments/1097.clarification
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Reference MSCs where MSCs were not being referenced.
* Alter language to appear consistent and from a single voice.
* Bundle and group various changes together (will affect the final changelog - the rendered one still doesn't bundle appropriately).
* Move entries to the spec area they are intended to be in.
* clarify federation Authorization header an add destination property
* add changelogs
* some clarifications
* more clarifications, fixes
* use HTML in the added-in/changed-in shortcodes
* Apply suggestions from code review
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Italicise primes and brackets in state res desc
I don't like it but it seems to make things look decent in Firefox.
This is probably good enough---we're not Knuth, after all.
Additionally I have avoided the use of `*E*'s` as in "E's prev_events"
since the apostrophe looks poor here.
Resolves#774.
An alternative to #1040.
* Changelog
The spec had an erroneous `room_id` field in a m.typing EDU entry of /sync, `m.read` receipts in `/sync`, and `m.fully_read` room account data objects in the spec. None of these are necessary nor used in practice.
Checking part of the ecosystem for whether clients look for, or homeservers include, these room_id fields, I found that:
Element does not require them, nor does Synapse include them.
Ruma does not include them.
Dendrite does not include them.
nheko/mtxclient does not look for them.
This change removes room_id from the example and OpenAPI schema in each case mentioned above. It only affects the Client-Server spec - the Server-Server spec text remains unchanged.
The field was initially introduced in 0f28f83.
Fixes#3641
The spec says the name field in m.room.name events must not exceed 255 bytes but no servers actually enforce this over the C-S API. Clients should probably already be truncating room names to an appropriate length for their user interface.
Signed-off-by: Aaron Raimist <aaron@raim.ist>
* Fix membership state table and diagram
There were 2 missing cases which are legal:
* `invite->knock` (a fairly silly thing to do, but legal under the auth rules)
* `external->leave (via /kick)` (another somewhat silly thing to do, but no different than `external->ban (via /ban)`)
The state table considered the first as illegal, which is untrue.
* Changelog
* Make the graph prettier
* Update changelogs/client_server/newsfragments/3730.clarification
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Otherwise they are inline into the paragraph without punctuation, and
hard to read.
I'm guessing that pandoc did a poor job of converting a LaTeX
`begin{description}...\end{description}` or `\paragraph{...} ...` to
Markdown.
This PR aims to correct several occurances of the old repo link in proposals.md
I have not corrected all of them as i do not wish to say that i know the correct way we should word things in these situations. The primary changes are replacing all mentions of contributing.rst with the updated link that will work.
I also changed the line about related MSCs or Doc issues to be Spec issues since i think this is a clear enough case for me to be willing to guess what is appropriate.
As per MSC3567, the `from` parameter is now optional for the `/messages` endpoint to allow fetching first or latest room content without having to rely on `/sync`
https://github.com/matrix-org/matrix-doc/pull/3567
* Configure syntax highlighter to use CSS classes
the inline `style` attributes cause CSP errors (and don't work). Instead, we
can use proper CSS classes.
* Configure response headers for Hugo dev server
make the dev server serve response headers which match the live site, for
better testing.
* Fix m.login.appservice -> m.login.application_service
Implementations seem to agree with the proposal, so I'd suggest we fix the typo in the spec. I don't *think* this needs a MSC as the original proposal was fine, and this was just a copy error.
* Create 3711.clarification
* Update 3711.clarification
* Update changelogs/3711.clarification
Co-authored-by: Travis Ralston <travisr@matrix.org>
Co-authored-by: Travis Ralston <travisr@matrix.org>
* Fix knock->leave transition in auth rules
This was an oversight from knocking being added.
For safety, this has been verified as at least intended by Synapse to work:
f5e2cde3f5/synapse/event_auth.py (L390-L391)
* changelog
* MSC3676: Transitioning away from reply fallbacks
* msc number
* md fails
* typoe
* Update proposals/3676-transitioning-away-from-reply-fallbacks.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* incorporate feedback
* consolidate justification
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Fixes#3305Fixes#3380
The idea here is to better distinguish between a 'raw' event (as we send over the wire), and the
'serialised' format, as sent in responses to the C-S api and in `PUT /_matrix/app/v1/transactions/{txnId}`.
It's made more complicated by the fact that there are _two_ serialisation formats, one used by `/sync`
and `/notifications`, and one by everything else (the difference being whether `room_id` is included).
In an ideal world, we wouldn't repeat `SerialisedEvent` every time it's used, and instead just link to the
first reference, but that's a job for another day.
Another job for another day is to get rid of things like `sync_state_event.yaml` (which is now used
only in one place, so should be inlined.)
* Update documentation style & fix room version heading order
Also add a missing signing key section to v6.
This additionally contains various edits to the fragments to have them make a little bit more sense in context.
Finally, this updates various aspects of the documentation style which haven't previously been considered - they're added here considering we're in the area.
* changelog
* enhanced changelogs
* Minor wording adjustments
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update several spots where C-S API was still using r0 APIs
Signed-off-by: Aaron Raimist <aaron@raim.ist>
* Add changelog
Signed-off-by: Aaron Raimist <aaron@raim.ist>
Fixes#2237.
Corrects the response schemas for:
```
PUT /user/{user_id}/account_data/{account_dataType}
PUT /user/{user_id}/rooms/{roomId}/account_data/{type}
PUT /directory/list/room/{roomId}
PUT /sendToDevice/{eventType}/{txnId}
POST /account/3pid
POST /account/3pid/add
POST /account/3pid/bind
```
* Room versions 8 and 9: Restricted rooms
MSCs:
* https://github.com/matrix-org/matrix-doc/pull/3083
* https://github.com/matrix-org/matrix-doc/pull/3289
* https://github.com/matrix-org/matrix-doc/pull/3375
* Changelogs
* Capitalization
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Remove verbiage for spaces because they don't exist
* Iterations on text
* Another clarification
* Make error code descriptions consistent
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Incorporate from merge
* Misc language update per review
* Update accuracy before splitting auth rules
* fix wtf moment
* Fix up v8 and v9 to match "fully specify room versions"
* Scope auth events selection to room version
* Apply consistency
* Add changelogs
* Review part 1
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Split out redaction sections
* Clarify general case of join conditions
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* First iteration of specifying Spaces
MSCs:
* https://github.com/matrix-org/matrix-doc/pull/3288
* https://github.com/matrix-org/matrix-doc/pull/2946
* https://github.com/matrix-org/matrix-doc/pull/1772
Note that this makes modifications to the underlying MSCs as well. These are intended to be minor edits to aid clarity/accuracy of the MSCs, as per the proposal process. Functionally, clients and servers might need to change their behaviour slightly as is expected of implementing this stuff early. Synapse has these changes (alongside backwards compatibility) here: https://github.com/matrix-org/synapse/pull/11667
* add changelogs
* Accuracy per review
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* fully prefix new endpoints
* Fully prefix endpoint in 3616 too
* Fix ordering example
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Initial cut of MSC to standardize from being optiona on /messages requests.
* Fix typo.
Co-authored-by: Travis Ralston <travisr@matrix.org>
* Clarifications of start/end.
* Add information about back-paginating excluded events.
Co-authored-by: Travis Ralston <travisr@matrix.org>
* initial version of serverside aggregations proposal
* fix MSC numbers
* clarification
* add e2ee section from 2674 here, as it is only needed for server-side aggregations
* move edge case wrt to calling /context on a relation here from 2674
* fix typo
* clarify which APIs should bundle relations
* move stale_events over to future extensions section
* summarize stale_events and make tone conditional to mark that is not part of the MSC
* casing and wording
* clarify in summary an API for requesting relations is also proposed
* remove proposal for batch get event api as is unused and unimplemented
* attempt to clarify relations vs aggregations
* clarify pagination and align it with synapse impl already in the wild
* conciseness
* better headers
* clarify that relations are always returned, contrary to aggregations
* document the limitation of the event type not being known in e2ee rooms
* specify that redacted relations are not aggregated
* remove type in (non-binding) example as synapse doesn't do this
* mention that these are just examples
* clarify that this is a non-normative example
* Update proposals/2675-aggregations-server.md
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
* add http method for endpoint list
* line break
* remove "unbundled relations" term, it's just confusing
instead use relation events,
with the bundled form now called aggregation
also restructure the headings so we have on section about aggregations
and another one about querying relation events
* some more restructuring of text after changing doc structure
* mention original_event for m.replace relations
* remove dir param as it is unused and unimplemented
* clarify that relating pending events should happen by transaction_id
* remove unimplemented /aggregations/{eventID}//{eventType}/{key}
endpoint
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* mention that the server might not be aware of all the relations
* clarify that redacted events should still return their relations and aggregations respectively
* remove /context edge case, it should not be special-cased
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* bad example, replies doesn't use relations
* clarify that we dont bundle discrete events
* clarify that we dont bundle discrete events, again
* improve example
* clarify this MSC does not use a prefix
* better english
* clarify pagination in example
* better english
* remove contradication: m.reference doesn't support pagination but example mentions it
* double punctuation
* clarify that only the bundled aggregation limit for truncation can't be set by the client, /aggregations does have a limit param
* move e2ee limitation to limitations section
* clarify prefixes
* mention that state events never bundle aggregations
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* add that the visibility of relations can derive from that of the target
* typsos
* be more explicit
* moar rewording
* keep related parts together
* don't make a relation invisible because the target event isn't
also clarify what to do with relations for which the target is invisible
* Update proposals/2675-aggregations-server.md
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
* better words
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* be more precise when clients should ensure the key is shared
* mention that ignored users can cause different aggregations for users
* move visibility rule changes to MSC3570
* don't overspecify visibility limitation, allow for unspecified behaviour
as synapse includes the invisible events in the aggregation
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* move non-normative note to below example
* make rel_type mandatory as the response structure doesn't allow for mixing types
* fix typo/thinko
* make pagination forward only as there is no use case for backwards
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* add non-normative aggregation examples
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* use relation type rather than rel_type
the former is already define as the latter in MSC 2674
* change trailing slashes remark to event_type, rel_type is mandatory now
* reword and split out client-side aggregation section
* rename parent event to target event, the term used elsewhere
* apply suggestion
* apply suggestion
* remove pagination
* remove mentions of /aggregations endpoint after removing pagination
* add note about not bundling into state events
* restructure headers so more of the aggregations stuff is under section
* make rel_type mandatory for /relations and better wording
* remove confusion that aggregations contain more info than relations
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* mention that tokens from /sync, /messages can be used on /relations
* try not to be overly prescriptive
* remove edge case of ignoring events without target event, as ignoring is not always safe
* clarify limitation for encrypted rooms
* make rel_type optional again for /relations
* Update proposals/2675-aggregations-server.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
* mention requires auth and rate-limited on /relations
* replace hypothetical examples for bundled aggregations with non-normative ones
* move to MSC 2676 as it's specific to edits
* dont repeat how local echo using transaction_id works
Co-authored-by: Bruno Windels <bruno@windels.cloud>
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
Now that we've dropped the old build pipeline (and an assets directory does not exist in the repo any longer, we can rename the hugo version of the assets (assets-hugo) created during the build tools migration back to simply assets.
* Add registration token UIA type
MSC: https://github.com/matrix-org/matrix-doc/pull/3231
**Note**: This introduces the endpoint as v1 rather than r0 given the global versioning changes landed between the acceptance of the MSC and now.
* Fix swagger
* Changelogs
* Update data/api/client-server/registration_tokens.yaml
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Fix rendering of response examples
Fixes the autogeneration of JSON examples for array objects. This fixes a
number of "Specification error: Example invalid or not present" errors in the
rendered spec.
* Unbreak examples for non-objects/arrays
The previous change had broken auto-generated examples for everything that
wasn't an object or array; fix it up again.
* Remove conditions on $example
Everything should now have a generated example, so the condition is
redundant. Furthermore it was suppressing examples for APIs where the example
was an empty dict.
* Copy spec PR near-verbatim from past PR
With light review being addressed.
https://github.com/matrix-org/matrix-doc/pull/3168
* Alter for modern day
* Add changelog
* specify that we're using the grammar
* Add HTTP 403 to possible profile responses
Some servers may not allow profile lookup over federation, and thus
respond to GET /_matrix/client/v3/profile/{userId} with an HTTP 403.
For example, Synapse can be configured to behave in this way by setting:
allow_profile_lookup_over_federation=false
Thus, this behavior already exists in the wild, and may cause issues for
clients such as https://github.com/vector-im/element-web/issues/17269.
Synapse could alter its behavior and return an HTTP 404 in these cases,
but amending the Spec seems preferable to align with extant behavior.
Further, allowing HTTP 403 gives clients more specific information as to
why a request has failed, enabling more precise error handling.
Signed-off-by: Dan Callahan <danc@element.io>
* Update changelogs/client_server/newsfragments/3530.clarification
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Annotate misc data about error
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Travis Ralston <travisr@matrix.org>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
Co-authored-by: Travis Ralston <travisr@matrix.org>
Fixes#3465. The change adds a line explicitly warning developers that the base_url of client well_known may or may not include a trailing slash and to be prepared to handle both cases.
* Add a release branch to avoid orphaned commits.
* Specify a patch process.
* Match reality and reference the internal deployment process.
This is largely what we do in practice now, including a created `release/v1.1` branch.
Switch to upstream and use a more recent version.
Fixes failure to edit on empty descriptions.
Signed-off-by: Alexandre Franke <alexandre.franke@matrix.org>
* MSC3419 - Guest state events
Let guests send state events. Needed for guests to work with native
group voip in #3401
* typo
* Update 3419-guest-state-events.md
incorporate @clokep clarification
* also let guests send non-m.room.message events in general.
* Update proposals/3419-guest-state-events.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/3419-guest-state-events.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* wordwrap
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
The documentation for the `/notifications` API had its own special definition
of what an Event was, which was used nowhere else.
The common definition isn't perfect, but it *is* common, so it gives us a
better starting place for improvement.
* Clarify that E0 and E1 are not returned
* Clarify that ASCII art diagram 2 refers to diagram 1
* Correct third ASCII art diagram
To match the spacing in. Borked in the move to new docs format.
55aed1d296/specification/client_server_api.rst (L1610-L1615)
* Make ASCII art 3 follow from ASCII art 2
* Explain how to fill the gap
* Create 3543.clarification
* Update content/client-server-api/_index.md
Co-authored-by: Travis Ralston <travisr@matrix.org>
Remove a bunch of fields from the `unsigned` property of PDUs. These things
shouldn't be passed over the Federation API, and they *really* shouldn't be
trusted if they are sent by another server.
* `replaces_state` *is* returned by Synapse, but probably shouldn't
be.
* `redacted_because`, `prev_sender` and `prev_content` are not sent by Synapse.
* initial version of event relationship MSC
* fix MSC numbers
* clarifications
* mention multiple relations per event might be useful, but postpone for a future MSC
* mention MSC 3051 for proposed multiple relations
* remove send_relation endpoint
* move e2ee section under sending relations
* mention limitation of leaving server-side aggregations out for now
* remove mentions of m.reference, we'll sort that out in another MSC
* whitespace
* argument why m.relates_to should be preserved by redactions more general
but still give example of redacted edits
* deal with this in the comments
* clarify the conditions to meet for a relation
* mention specifically that this does not replace replies (yet)
* clarify how general rel_types should be
* clarify that gaps may cause clients to be unaware of some relations
* Update proposals/2674-event-relationships.md
Co-authored-by: DeepBlueV7.X <nicolas.werner@hotmail.de>
* Update proposals/2674-event-relationships.md
Co-authored-by: DeepBlueV7.X <nicolas.werner@hotmail.de>
* make wording clearer and move to bottom of section
* remove this as references are not defined here anymore
* clearer wording
* move edge cases to other relevant mscs
* clarify that a goal of sticking to this format is backwards compat.
* mention MSC 3267, to which m.reference has been extracted
* Update proposals/2674-event-relationships.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2674-event-relationships.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2674-event-relationships.md
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
* Update proposals/2674-event-relationships.md
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
* Update proposals/2674-event-relationships.md
Co-authored-by: Travis Ralston <travpc@gmail.com>
* wrap lines
* better wording
* this is singular, really
* add example of event shape
* specify how invalid relations should be treated by the redaction algorithm
* fix typo
* split up redactions changes in separate MSC
* also add new msc to introduction
* reword why not adopt m.in_reply_to
* remove guidelines how to pick rel_type
* mention that the target event must exist in the same room
* spell out the conscious (subject, object, verb) triple idea.
* Spelling
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* remove paragraph saying what server should accept
* Revert "remove paragraph saying what server should accept"
This reverts commit e0271331b2e7dee236349aa63eec3cec7369e361.
* further specify that a server should reject invalid relations through the cs api
* linebreak
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Bruno Windels <bruno@windels.cloud>
Co-authored-by: DeepBlueV7.X <nicolas.werner@hotmail.de>
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Split the text about event IDs and event formats into separate sections. This
is largely to make it easier to link to, but I think the resulting text makes
more sense too.
The entries were text-less and not really helping anyone. They are included as pages because we need them for templating, but we don't need people to be able to land on them directly.
* Remove entries which don't affect the rendered spec (sorry people using the swagger schemas - we'll have to figure out a changelog for you). See https://github.com/matrix-org/matrix-doc/issues/3475
* Note that a breaking change is removed by this commit: key backup was introduced in this release cycle, so is not breaking.
* Use uniform references to MSCs ("as per MSC0000").
* General rewording to be consistent with the overall voice of the changelog.
* Condensing of entries where needed to make them fit in the changelog.
* Rewording to collapse entries into fewer lines.
* Spell "deprecation" correctly in file extension.
This fixes the behaviour to match what synapse implements in practice.
If you use threepidCreds, you will just get an error about a missing
threepid_creds field. Synapse also treats this as an object. All clients
also seem to send threepid_creds, if they work on Synapse. Since
matrix.org requires an email currently for registration, most clients
that implement registration, will hit this issue.
a0f48ee89d/synapse/handlers/ui_auth/checkers.py (L145)fixes#3156fixes#2189
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
* Fully specify room versions
* Misc typo clarifications
* Try to clarify redactions a bit
* Update content/client-server-api/_index.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update content/rooms/v6.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update content/rooms/v6.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Better describe client considerations
* Doc template params
* Move redaction "new stuff" to v3
* Remove unhelpful sentences about "here follows unchanged stuff"
* Simplify event signing text
* Clean up handling redactions sections
* Move v4's event schema to unchanged section
* Update content/rooms/v4.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Spaces Summary
* MSC2946
* Clarity
* More clarity
* Clarify what no room data means for clients
* Federation API
* Update 2946-spaces-summary.md
* auto_join filter
* Blurb on auth for fed api
* Update to reflect MSC1772 changes
* Mention auth chain on federation api
* Add 'version' field
* Stripped state; remove room versions
* Update 2946-spaces-summary.md
* Update proposals/2946-spaces-summary.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Replace with link to draft doc.
* Add a preamble and copy the current draft API.
* Switch to using stable identifiers (and add an unstable identifiers section).
* Updates / clarifications.
* Fix typo.
* Clean-ups.
* Update proposals/2946-spaces-summary.md
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Drop unstable identifiers from MSC1772.
* Various updates and clarifications.
* Include the origin_server_ts in the response, as needed by MSC1772.
* Rename a parameter for clarity.
* Fix typo.
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
* Various clarifications based on feedback.
* Add auth / rate-limiting info.
* Combine some double spaces.
* Use only GET endpoints.
* Add notes about DoS potential.
* Tweaks from review.
* Add context about why stripped events are returned.
* Remove some implementation details.
* Add notes on ordering.
* Remove unnecessary data.
* Clarify the server-server API.
* More clarifications.
* Remove obsolete note.
* Some clarifications to what accessible means.
* Update notes about sorting to include the origin_server_ts of the m.space.child event.
This reverts commit af8c7b04d9f87bb2c4292a549b7db36ae6ef2324.
* Only consider `m.space` rooms and do not return links to nowhere.
* Updates based on MSC3173 merging and updates to MSC3083.
* Updates per MSC2403.
* Remove field which is not part of the C-S API.
* Rewrite the proposal.
* Handle todo comments.
* Update URLs.
* Rename field.
* Updates based on implementation.
* Clarify the state which is persisted.
* Expand notes about errors.
* Update MSC with pagination parameter.
* Fix wrong endpoint.
Co-authored-by: Matthew Hodgson <matthew@matrix.org>
* Clarifications based on implementation.
* Remove empty section.
* Fix typo.
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Rename field in example.
* Clarify error code.
* Clarify ordering changes.
* Clarify wording.
Co-authored-by: Travis Ralston <travisr@matrix.org>
* Fix typos.
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Clarify that rooms do not belong to servers.
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Fix example to use correct URL.
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Clarify using local vs. remote data.
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Clarify bits aboud stripped state.
* Clarify access control of federation responses.
* Clarify error code.
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Be less prescriptive about expiring data.
* Limit must be non-zero.
Co-authored-by: Travis Ralston <travisr@matrix.org>
* Rate limiting.
Co-authored-by: Travis Ralston <travisr@matrix.org>
* Add a note about room upgrades.
* Update stable URLs per MSC2844.
* Clarify federation return values.
* Clarify `origin_server_ts`.
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
* Tweak wording around `inaccessible_children`.
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <richard@matrix.org>
Co-authored-by: Patrick Cloke <patrickc@matrix.org>
Co-authored-by: Matthew Hodgson <matthew@matrix.org>
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Travis Ralston <travisr@matrix.org>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
* Build release tags of the spec
* Update .github/workflows/main.yml
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
* Move historical (future old) job out to its own thing
* Update for new baseurl setup
* Use hugo config overrides instead
* Remove mistakenly re-added matrix.org poke
* Restore npm stuff to main branch representations
* [2] Restore npm stuff to main branch representations
* Update .github/workflows/main.yml
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* add room type in store invite
* update dev identifier purpose
* Added clarification if type not present, and on email generation
* Update proposals/3288-pass_room_type_in_3pid_invite.md
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Update proposals/3288-pass_room_type_in_3pid_invite.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/3288-pass_room_type_in_3pid_invite.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/3288-pass_room_type_in_3pid_invite.md
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Update proposals/3288-pass_room_type_in_3pid_invite.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/3288-pass_room_type_in_3pid_invite.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update 3288-pass_room_type_in_3pid_invite.md
fix typo
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Remove extra pyprojects and update changelog docs
* Add script for rendering the changelog
* Add docs for how to release the spec
* Move legacy changelogs out of the way
* Inline resolve_references in dump-swagger
Since this is the only bit of the old templating system we still use, let's
inline it.
OrederedLoader and OrderedDict are now redundant, because all dicts in Python
preserve insertion order.
* Remove the old templating system
We've now replaced the old templates with hugo, so we can get rid of this mess.
PyYAML 6.0 was released yesterday, and it finally drops support for `yaml.load`
without a `loader` argument, which has been deprecated since 2017.
We don't use any fancy yaml objects, so `safe_load` should be fine.
* Introduce a new "added-in" template and use it on endpoints
* Use "added-in" on schema properties too
* Annotate sections of the spec with their added versions
* Demo of "added-in" on a room version (to be fleshed out)
* Use clearer versioning semantics
* Update and fix validator for Swagger custom properties
* Fix docs
* Cut/paste room version spec to its own page
* Move grammar to bottom + add feature matrix
The version grammar is not as interesting as the actual room versions, so this moves that whole section to the bottom.
* Fix all links to room versions
As "unstable" changes and "latest" becomes no more, these sorts of links should be updated to reference the approximate section they intended to reference at the time of writing.
This change tries to link up the relevant bits for the time of the proposal, though it's not a perfect match. Some MSCs were brought into the spec before an API version could be assigned to the "old" text, so github permalinks are used instead.
* Refresh tokens MSC
* MSC2918: minor changes
* MSC2918: access token expiration as milliseconds
* MSC2918: account registration API changes
* MSC2918: fix `expires_in_ms` example
* MSC2918: add precision about token revocation
* MSC2918: specify error codes for the refresh API
* MSC2918: clarify that the change also applies to ASes
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* MSC2918: clarify what problem this MSC solves
* MSC2918: minor formatting and rephrasing
* MSC2918: clarify ratelimiting, masquerading and authentication on refresh token API
* MSC2918: make expires_in_ms/refresh_token optional
* MSC2918: soft logout in refresh token API
* MSC2918: add detailed rationale
While not exhaustive, it outlines a few attack vectors this MSC tries to
mitigate.
* MSC2918: minor fix
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* MSC2918: clarifications on backward compatibility
* MSC2918: advertise support in the request body
* MSC2918: clarify on what happen when token expire
* MSC2918: remove redundant precision about token expiration and lifetime
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* MSC2918: minor clarification
* MSC2918: soft logout when using expired token
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Proposal for token authenticated registration
Signed-off-by: Callum Brown <callum@calcuode.com>
* Hard-wrap lines
Signed-off-by: Callum Brown <callum@calcuode.com>
* Link to released version of spec
Signed-off-by: Callum Brown <callum@calcuode.com>
* Fix unstable prefix wording
Signed-off-by: Callum Brown <callum@calcuode.com>
* Tokens should only be invalidated after registration
Signed-off-by: Callum Brown <callum@calcuode.com>
* Change auth type to m.login.registration_token
This is consistent with the other UIAA auth types, and does not suggest
that other `m.login.*` types cannot be used for registration.
Signed-off-by: Callum Brown <callum@calcuode.com>
* Add proposal for checking the validity of a token
Signed-off-by: Callum Brown <callum@calcuode.com>
* Fix validity checking endpoint
Signed-off-by: Callum Brown <callum@calcuode.com>
* Limit allowed characters and length of token
This allows tokens to be used easily in query parameters
Signed-off-by: Callum Brown <callum@calcuode.com>
* Give reason for limiting token length and chars
Signed-off-by: Callum Brown <callum@calcuode.com>
* Note all stages must be complete for registration
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
* Fix mistake in MSC number
Signed-off-by: Callum Brown <callum@calcuode.com>
* Validity checking should be rate limited
Signed-off-by: Callum Brown <callum@calcuode.com>
* Change v1 to r0
Signed-off-by: Callum Brown <callum@calcuode.com>
* Include `.` and `~` in allowed characters for registration tokens
For consistency with the unreserved URL characters in RFC3986
https://www.ietf.org/rfc/rfc3986.html#section-2.3
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Clarify how redacted_because actually works for events
* changelog
* mention federation
* Fix wording
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
This tweaks the DAG to be simpler, with two linear event chains E4 -> E3
-> E2 -> E1 and E6 -> E5 -> E2 -> E1. The extremities of the DAG are now
the first and only point in the DAG where multiple event parents occur.
Since the point of the diagram is to demonstrate this very situation,
it's better didactically if there is only one such situation in the
diagram.
The Pagination section in the C-S API was, basically, full of rubbish. I think that anything of any value it contained was repeated either directly on the API definitions or in the text specific to syncing at https://spec.matrix.org/unstable/client-server-api/#syncing.
The conventions I've added to the Appendices are based on the discussions in #1898. They are there because I don't want to have to go through it all again next time we add a paginated API.
Fixes: #1898Fixes: #2268
Apparently, in response to a /_matrix/federation/v1/user/devices/{userId} request, Synapse actually returns a key called "self_signing_key" instead of "self_signing_keys".
This change drops the Origin and Accept header names from the
recommended value for the CORS Access-Control-Allow-Headers header. Per
the CORS protocol, it’s not necessary or useful to include them.
Per-spec at https://fetch.spec.whatwg.org/#forbidden-header-name, Origin
is a “forbidden header name” set by the browser and that frontend
JavaScript code is never allowed to set.
So the value of Access-Control-Allow-Headers isn’t relevant to Origin or
in general to other headers set by the browser itself — the browser
never ever consults the Access-Control-Allow-Headers value to confirm
that it’s OK for the request to include an Origin header.
And per-spec at https://fetch.spec.whatwg.org/#cors-safelisted-request-header,
Accept is a “CORS-safelisted request-header”, which means that browsers
allow requests to contain the Accept header regardless of whether the
Access-Control-Allow-Headers value contains "Accept".
So it’s unnecessary for the Access-Control-Allow-Headers to explicitly
include Accept. Browsers will not perform a CORS preflight for requests
containing an Accept request header.
Related: Related: https://github.com/matrix-org/synapse/pull/10114
Signed-off-by: Michael[tm] Smith <mike@w3.org>
This resolves a jarring text overlap issue with the sidebar by only adjusting
the `max-height` at larger widths, which matches the original rule being
overridden.
Fixes https://github.com/matrix-org/matrix-doc/issues/3049
Fixes#3146.
This PR changes the Matrix Spec Proposals page to clarify that implementations **do not** need to wait until a spec release to use stable prefixes, but that they can do so after the corresponding MSC has been merged. The justification is that once an MSC has been merged, it's fairly guaranteed that it will land in the spec. Yet it will take time for the spec release process to run its course, and we shouldn't make implementations wait for that.
The exception to this is if implementating a feature in a backwards-compatible way requires a new spec version to indicate to clients/servers that a feature has been added/changed. This situation is rare though, and most implementations won't fall into this category.
It wasn't entirely clear what should happen to the FCP timer (and state) when a concern is raised during FCP. After some discussion, we agreed that when a concern is raised:
1. FCP will continue to not conclude until at least 5 days have passed, but once those 5 days are up it *still* won't conclude until all concerns raised during FCP are resolved.
2. If a concern warrants a large enough change in the document, then the Spec Core Team may consider cancelling FCP and restarting the timer in order for people to have some time to think about and review the new changes.
The regex of allowed characters for a `client_secret` parameter is `[0-9a-zA-Z.=_-]`.
This PR updates the `client_secret` spec examples, which currently include an invalid character (an apostrophe).
This PR does two things:
* Updates the git submodule for the new spec hugo theme ([google/docsy](https://github.com/google/docsy)) to our fork ([matrix-org/docsy](https://github.com/matrix-org/docsy)) which has a couple changes to load JS from local sources instead of remote, as well as allowing sites to override the URL that font CSS files are loaded from. Note that my definition of "font CSS" files here as CSS files that contain settings and point to locations of where font files (`.woff2`) are located.
* Adds a script (and the files generated as a result of running that script) that can take a google fonts URL, download the fonts it points to and spit out those fonts as well as a font CSS file pointing to them for local distribution. We then use the resulting font CSS file in our project variables.
This brings the benefit of not serving files from a CDN which can track users across the web, as well as inadvertently pinning docsy to a specific commit. The downside is that we need to remember to update [matrix-org/docsy](https://github.com/matrix-org/docsy) when needed (and apply the patches on top, though they're quite small).
Since we're deploying to https://spec.matrix.org/unstable now. This only updates the `baseURL` for our buildkite build. The default is still `/` when doing a local build.
This PR attempts to update the CI of matrix-doc to build [the new spec redesign](https://github.com/matrix-org/matrix-doc/issues/2906). It does so by additionally building the new spec in parallel to the old. The plan is to continue to host the old spec at https://matrix.org/docs/spec, while the new spec will be at https://spec.matrix.org. Eventually we will retire the old version of the spec, and have the old URL redirect to the new one.
In detail, this PR:
* Adds a new step to CircleCI to build the new spec with `hugo`. This step uses alpine, grabs some dependencies, and then builds the HTML.
* We needed to hand some specific options to hugo for CircleCI in order to continue allowing CircleCI to host temporary builds of the spec after each CI run. This required changing some assumptions related to relative paths.
* CircleCI's artifacts hosting is also quite limited. Specifically it will not automatically resolve `/some/path` to `/some/path/index.html`, which our hugo theme relied on. Fixes were implemented for this, but we may want to consider switching away from CircleCI artifacts as a host, and using something like [netlify](https://www.netlify.com/) instead.
* Modifies the existing Buildkite pipeline step to build both the new spec in a separate step. It additionally modifies the old spec to be built with alpine. (Separate out into another PR)
* We'd like to separate out the deployment of matrix.org from the new spec. Therefore a new step, with a separate artifact build (`spec.tar.gz`). We will eventually remove the old step and the matrix.org build trigger.
* Modifies `pyproject.toml` to update the config of [giles](https://github.com/OpenAstronomy/baldrick/blob/master/baldrick/plugins/circleci_artifacts.py), which is what creates the "docs", "swagger" links in the CI steps for matrix-docs PRs.
* A new step was added for the new spec. The old spec was renamed to "legacy".
Historical note: this was originally a series of several commits, spread out
over several weeks. They have been squashed together to make `git annotate`
work properly.
The original commits were:
* 91ab3934 <Will> 2021-01-25 21:16:42 -0800 Add raw API end event schemas into /data directory
* aae22f47 <Will> 2021-01-25 21:33:06 -0800 Remove non-data files
* 1092d4ca <Will> 2021-01-26 20:41:33 -0800 Add data-compatiuble extension (.yaml) to all data files that currently omit one
* 21060109 <Will> 2021-01-26 20:57:28 -0800 Remove symlink to event-schemas, and update openAPI schema paths accordingly
* 4f633845 <Travis Ralston> 2021-04-12 21:54:54 -0600 Fix event schema examples too
* 301c7b2f <Will> 2021-02-05 10:15:42 -0800 Restore docs describing OpenAPI extensions that we use
check-swagger-sources also had a bug which caused it to fail while validating the directory
structure of /data/api. This was fixed by @KitsuneRal - thank you!
I'm doing this for two reasons:
1) If I ever wanted to create another knock-related MSC, it would be nice to be able
to give it a different namespace for endpoints, such as xyz.amorgan.knock2/knock. If
we were only using xyz.amorgan as the namespace for endpoints, that restricts that
namespace to only work for one MSC which attempts to use /knock as part of an endpoint.
2) I accidentally made the implementation use xyz.amorgan.knock/knock :)
Got a bit confused with the sender and state_key being different in invite
membership events. In case of a knock, even if the knock event is being
inserted into the room by another homeserver over federation, the sender
of the event is still the knocking user, just like the state_key.
This aligns with the current v2 federation endpoints. However, we're still using v1
as a prefix here as it is still the first version of this endpoint.
* add a base file
* Fix directory name
* Added translation using Weblate (English)
* Translated using Weblate (English)
Currently translated at 1.6% (1 of 64 strings)
Translation: matrix-doc/SAS Emoji v1
Translate-URL: https://translate.riot.im/projects/matrix-doc/sas-emoji-v1/en_EN/
* add english files
* delete english files
* Added translation using Weblate (English)
* Added translation using Weblate (English)
* Do manual translations
* Deleted translation using Weblate (English)
* Deleted translation using Weblate (English)
* Add a script to update the definitions with the translations
* update i18n
* Add a note to the spec about translations
* changelog
* Ensure translations end with json
- Authority part semantics are no more prescribed; authority part has
defined syntax but reserved for future use.
- Moved away non-normative parts to "Discussion" and/or "Alternatives"
- Added `action=chat`
- Extended `via=` applicability to non-roomid cases to compensate
dropping the authority part semantics.
- Added a reference algorithm to parse a URI.
- Closed outstanding questions/discussion points.
- Added more cases for future evolution.
- Added "minimal syntax" options to the discussion of possible
alternatives
* Most of the changes: align to the $ref object definition
(https://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03#section-3)
that says that any attribute other than $ref be ignored.
* Remove extraneous leading ./ in $ref paths
* Fix an apparent typo in registration.yaml:
/account/password/msisdn/requestToken used a file from ../identity/*
instead of its c2s namesake.
MSC: https://github.com/matrix-org/matrix-doc/pull/2209
The changes are slightly difficult to word without dumping the text in and playing a game of spot the difference, so we now use our pre-existing pygments support to render a representation of the difference. The difference is shown in markdown-like format instead of RST for ease of understanding. It's also not rendered HTML for largely complexity reasons.
We stick it in a client section of v1 as the earliest version to define the algorithm is v1, and the client-server spec tells clients to use this algorithm.
MSC: https://github.com/matrix-org/matrix-doc/pull/2432
This commit does not deal with areas which will be covered by the room version specifications (namely the redaction algorithm).
It feels a bit overly cruel to completely obliterate all mentions of `m.room.aliases` from the spec as client/server developers may encounter the event type in the wild. To ensure that CTRL+F still works, a brief mention that they do nothing has been put in place, leaving no other references (except the redaction algorithm - see previous paragraph).
The device keys structure in queryKeys is not the same as the one
defined in device_keys.yaml (it adds things on top of it).
Signed-off-by: Alexey Rusakov <Alexey.Rusakov@pm.me>
Fixes the typo in the Request Authentication python example. It seems like a copy paste error.
Closes: #2509
Signed-off-by: Rudi Floren <rudi.floren@gmail.com>
I couldn't find any other reference to a state_type within the entire specification. I assume this is supposed to be the event_type? This aligns with the description of changes resulting from a state update.
Co-Authored-By: David Baker <dbkr@users.noreply.github.com>
Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-Authored-By: Erik Johnston <erikj@jki.re>
Part of MSC2140
Convert status codes to strings if there is a string status code. Fixes a build error when we mix 4xx and 403 in the same definition. We also have to correct stringified numbers to pass the build.
Affects the title and the table of contents. We can't realistically alter just the table of contents, but the table of contents is generated from this header.
Fixes https://github.com/matrix-org/matrix-doc/issues/1800
The spec states that the action of a room key request cancellation
should be "cancel_request" but every known implementation uses
"request_cancellation" instead.
This patch fixes the spec to reflect the implementations.
Used **Note** to describe notes around the authorisation rules. Otherwise restored the original state for the consequences from the auth rules.
Moved the clarification regarding default power levels up above the auth rules. Removed third sentence. And followed @turt2live's example, but opted for "for users in that room" because the default user power level is applied to all users.
Added missing added and removed to the rule, because these keys are not required for m.room.power_levels. Also moved the note down to the Note section.
The rules for m.room.power_levels power were somewhat unclear regarding the behaviour towards the always present keys, such as kick and ban. Additionally, it is now also clarified that in the users and events dictionary also added and removed keys are taken into consideration.
The server-server specification describes a "reference hash" of an event
and how to calculate it, but is otherwise not mentioned anywhere else in
the document. This change adds a sentence to explain that they are used
for event identifiers in later room versions, which are described in
other documents.
Signed-off-by: Jimmy Cuadra <jimmy@jimmycuadra.com>
- indicate how to use MSC 1946 to store/share private keys
- add signing by devices to enable migrating from device verifications
- add information about signature upload failures and M_INVALID_SIGNATURE code
- add security consideration
This clarifies the `.m.rule.room_one_to_one` push rule by adding a condition on
event type. Some parts of the spec already had this info, while others were
missing it. Synapse has had this behaviour since the push rule appeared.
Fixes https://github.com/matrix-org/matrix-doc/issues/2150
* Switch "an SAS" back to "a SAS"
* Remove the `next_method` field from m.key.verification.start$m.sas.v1
but add additional clarification to its description on
m.key.verification.start that it is never present for methods that
verify keys both ways.
Currently the *m.key.verification.start* event appears twice with the
exact same title, in the "Key verification framework" section and the
"Short Authentication (SAS) verification" section. It's not immediately
clear that the first occurrence describes the format of the event in
general terms and that the second occurrence describes the fields when
the *m.sas.v1* verification method is being used. This is a similar
relationship to the *m.room.message* event and its various *msgtype*
variants.
This commit does three things:
* It tweaks the generation of the documentation to change the title
of the second occurrence of *m.key.verification.start* to
distinguish it from the first.
* It updates the language in the description of the two versions of the
event to better describe the relationship between the two.
* It adds the optional `next_method` field to the schema of the
*m.sas.v1* variant, as specified in the general form of
*m.key.verification.start*.
Signed-off-by: Jimmy Cuadra <jimmy@jimmycuadra.com>
m.room.message msgtypes.
Now that content referenced by the *m.audio*, *m.file*, *m.image*, and
*m.video* message types can be encrypted, the `url` field is required
*only* if the content is unencrypted. The "required" designation in the
event schemas (which prefixes the field description with "Required" in
bold in the generated HTML) is used to indicate fields which must always
be present, and this is no longer the case.
Signed-off-by: Jimmy Cuadra <jimmy@jimmycuadra.com>
so that a matrix client A can check it is synchronised with the backup.
If not, that means that another client B has pushed keys client A does not have locally. Client A should then propose to the end user to retrieve keys from the backup.
This repository contains the Matrix Specification. The current release version is rendered at https://spec.matrix.org, while the latest available build of the `main` branch is at https://spec.matrix.org/unstable.
Developers looking to use Matrix should join [#matrix-dev:matrix.org](https://matrix.to/#/#matrix-dev:matrix.org)
on Matrix for help.
Spec authors and proposal writers are welcome to join [#matrix-spec:matrix.org](https://matrix.to/#/#matrix-spec:matrix.org).
We welcome contributions! See [CONTRIBUTING.rst](./CONTRIBUTING.rst) for details.
## Structure
The Matrix spec is compiled with [Hugo](https://gohugo.io/) (a static site generator) with the following structure:
* `/assets`: assets that need postprocessing using [Hugo Pipes](https://gohugo.io/hugo-pipes/introduction/).
For example, Sass files would go here.
* `/content`: files that will become pages in the site go here. Typically these are Markdown files with some YAML front
matter indicating, [among other things](https://gohugo.io/content-management/front-matter/), what layout should be
applied to this page. The organization of files under `/content` determines the organization of pages in the built
site.
* `/data`: this can contain TOML, YAML, or JSON files. Files kept here are directly available to template code as
[data objects](https://gohugo.io/templates/data-templates/), so templates don't need to load them from a file and
parse them. This is also where our OpenAPI definitions and schemas are.
* `/layouts`: this contains [Hugo templates](https://gohugo.io/templates/). Some templates define the overall layout of
a page: for example, whether it has header, footer, sidebar, and so on.
* `/layouts/partials`: these templates can be called from other templates, so they can be used to factor out
template code that's used in more than one template. An obvious example here is something like a sidebar, where
several different page layouts might all include the sidebar. But also, partial templates can return values: this
means they can be used like functions, that can be called by multiple templates to do some common processing.
* `/layouts/shortcodes`: these templates can be called directly from files in `/content`.
* `/static`: static files which don't need preprocessing. JS or CSS files could live here.
* `/themes`: you can use just Hugo or use it with a theme. Themes primarily provide additional templates, which are
supplied in a `/themes/$theme_name/layouts` directory. You can use a theme but customise it by providing your own
versions of any of the theme layouts in the base `/layouts` directory. That is, if a theme provides
`/themes/$theme_name/layouts/sidebar.html` and you provide `/layouts/sidebar.html`, then your version of the
template will be used.
It also has the following top-level file:
* `config.toml`: site-wide configuration settings. Some of these are built-in and you can add your own. Config settings
defined here are available in templates. All these directories above are configurable via `config.toml` settings.
Additionally, the following directories may be of interest:
* `/attic`: Here contains historical sections of specification and legacy drafts for the specification.
* `/changelogs`: Various bits of changelog for the specification areas.
* `/data-definitions`: Bits of structured data consumable by Matrix implementations.
* `/meta`: Documentation relating to the spec's processes that are otherwise untracked (release instructions, etc).
* `/scripts`: Various scripts for generating the spec and validating its contents.
* `/packages`: Various packages for shipping spec files like OpenAPI bindings and data definitions.
## Authoring changes to the spec
Please read [CONTRIBUTING.rst](./CONTRIBUTING.rst) before authoring a change to the spec. Note that spec authoring takes
place after an MSC has been accepted, not as part of a proposal itself.
1. Install the extended version (often the OS default) of Hugo:
<https://gohugo.io/getting-started/installing>. Note that at least Hugo
v0.113.0 is required.
Alternatively, use the Docker image at
https://hub.docker.com/r/klakegg/hugo/. (The "extended edition" is required
to process the SCSS.)
2. Run `npm i` to install the dependencies. Note that this will require NodeJS to be installed.
3. Run `npm run get-proposals` to seed proposal data. This is merely for populating the content of the "Spec Change Proposals"
page and is not required.
4. Run `hugo serve` (or `docker run --rm -it -v $(pwd):/src -p 1313:1313
klakegg/hugo:ext serve`) to run a local webserver which builds whenever a file
change is detected. If watching doesn't appear to be working for you, try
adding `--disableFastRender` to the commandline.
5. Edit the specification 🙂
We use a highly customized [Docsy](https://www.docsy.dev/) theme for our generated site, which uses Bootstrap and Font
Awesome. If you're looking at making design-related changes to the spec site, please coordinate with us in
[#matrix-docs:matrix.org](https://matrix.to/#/#matrix-docs:matrix.org) before opening a PR.
## Building the specification
If for some reason you're not a CI/CD system and want to render a static version of the spec for yourself, follow the above
steps for authoring changes to the specification and instead of `hugo serve` run `hugo -d "spec"` - this will generate the
spec to `/spec`. If you'd like to serve the spec off a path instead of a domain root (eg: `/unstable`), add `--baseURL "/unstable"`
to the `hugo -d "spec"` command.
For building the OpenAPI definitions, create a python3 virtualenv and activate it. Then run `pip install -r ./scripts/requirements.txt`
and finally `python ./scripts/dump-openapi.py` to generate it to `./scripts/openapi/api-docs.json`. To make use of the generated file,
there are a number of options:
* You can open `./scripts/openapi-preview.html` in your browser, and then open the file by clicking on `Local JSON File`.
* You can run a local HTTP server by running `./scripts/openapi-http-server.py`, and then view the documentation by
opening `./scripts/openapi-preview.html` in your browser.
## Issue tracking
Specification issues are tracked on github at <https://github.com/matrix-org/matrix-spec/issues>.
See [meta/github-labels.rst](./meta/github-labels.rst) for information on what the labels mean.
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
swagger:'2.0'
info:
title:"Matrix Client-Server Room Banning API"
version:"1.0.0"
host:localhost:8008
schemes:
- https
- http
basePath:/_matrix/client/%CLIENT_MAJOR_VERSION%
consumes:
- application/json
produces:
- application/json
securityDefinitions:
$ref:definitions/security.yaml
paths:
"/rooms/{roomId}/ban":
post:
summary:Ban a user in the room.
description:|-
Ban a user in the room. If the user is currently in the room, also kick them.
When a user is banned from a room, they may not join it or be invited to it until they are unbanned.
The caller must have the required power level in order to perform this operation.
operationId:ban
security:
- accessToken:[]
parameters:
- in:path
type:string
name:roomId
description:The room identifier (not alias) from which the user should be banned.
required:true
x-example:"!e42d8c:matrix.org"
- in:body
name:body
required:true
schema:
type:object
example:{
"reason": "Telling unfunny jokes",
"user_id": "@cheeky_monkey:matrix.org"
}
properties:
user_id:
type:string
description:The fully qualified user ID of the user being banned.
reason:
type:string
description:The reason the user has been banned. This will be supplied as the
``reason`` on the target's updated `m.room.member`_ event.
required:["user_id"]
responses:
200:
description:The user has been kicked and banned from the room.
examples:
application/json:{
}
schema:
type:object
403:
description:|-
You do not have permission to ban the user from the room. A meaningful ``errcode`` and description error text will be returned. Example reasons for rejections are:
- The banner is not currently in the room.
- The banner's power level is insufficient to ban users from the room.
examples:
application/json:{
"errcode": "M_FORBIDDEN",
"error": "You do not have a high enough power level to ban from this room."
}
schema:
"$ref": "definitions/errors/error.yaml"
tags:
- Room membership
"/rooms/{roomId}/unban":
post:
summary:Unban a user from the room.
description:|-
Unban a user from the room. This allows them to be invited to the room,
and join if they would otherwise be allowed to join according to its join rules.
The caller must have the required power level in order to perform this operation.
operationId:unban
security:
- accessToken:[]
parameters:
- in:path
type:string
name:roomId
description:The room identifier (not alias) from which the user should be unbanned.
required:true
x-example:"!e42d8c:matrix.org"
- in:body
name:body
required:true
schema:
type:object
example:{
"user_id": "@cheeky_monkey:matrix.org"
}
properties:
user_id:
type:string
description:The fully qualified user ID of the user being unbanned.
required:["user_id"]
responses:
200:
description:The user has been unbanned from the room.
examples:
application/json:{
}
schema:
type:object
403:
description:|-
You do not have permission to unban the user from the room. A meaningful ``errcode`` and description error text will be returned. Example reasons for rejections are:
- The unbanner's power level is insufficient to unban users from the room.
examples:
application/json:{
"errcode": "M_FORBIDDEN",
"error": "You do not have a high enough power level to unban from this room."
summary:Create a new mapping from room alias to room ID.
operationId:setRoomAlias
security:
- accessToken:[]
parameters:
- in:path
type:string
name:roomAlias
description:The room alias to set.
required:true
x-example:"#monkeys:matrix.org"
- in:body
name:body
description:Information about this room alias.
required:true
schema:
type:object
properties:
room_id:
type:string
description:The room ID to set.
required:['room_id']
example:{
"room_id": "!abnjk1jdasj98:capuchins.com"
}
responses:
200:
description:The mapping was created.
examples:
application/json:{}
schema:
type:object
409:
description:A room alias with that name already exists.
examples:
application/json:{
"errcode": "M_UNKNOWN",
"error": "Room alias #monkeys:matrix.org already exists."
}
schema:
"$ref": "definitions/errors/error.yaml"
tags:
- Room directory
get:
summary:Get the room ID corresponding to this room alias.
description:|-
Requests that the server resolve a room alias to a room ID.
The server will use the federation API to resolve the alias if the
domain part of the alias does not correspond to the server's own
domain.
operationId:getRoomIdByAlias
parameters:
- in:path
type:string
name:roomAlias
description:The room alias.
required:true
x-example:"#monkeys:matrix.org"
responses:
200:
description:The room ID and other information for this alias.
schema:
type:object
properties:
room_id:
type:string
description:The room ID for this room alias.
servers:
type:array
description:A list of servers that are aware of this room alias.
items:
type:string
description:A server which is aware of this room alias.
examples:
application/json:{
"room_id": "!abnjk1jdasj98:capuchins.com",
"servers": [
"capuchins.com",
"matrix.org",
"another.com"
]
}
404:
description:There is no mapped room ID for this room alias.
examples:
application/json:{
"errcode": "M_NOT_FOUND",
"error": "Room alias #monkeys:matrix.org not found."
}
schema:
"$ref": "definitions/errors/error.yaml"
tags:
- Room directory
delete:
summary:Remove a mapping of room alias to room ID.
description:|-
Remove a mapping of room alias to room ID.
Servers may choose to implement additional access control checks here, for instance that room aliases can only be deleted by their creator or a server administrator.
operationId:deleteRoomAlias
security:
- accessToken:[]
parameters:
- in:path
type:string
name:roomAlias
description:The room alias to remove.
required:true
x-example:"#monkeys:matrix.org"
responses:
200:
description:The mapping was deleted.
examples:
application/json:{
}
schema:
type:object
404:
description:There is no mapped room ID for this room alias.
examples:
application/json:{
"errcode": "M_NOT_FOUND",
"error": "Room alias #monkeys:example.org not found."
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
swagger:'2.0'
info:
title:"Matrix Client-Server Room Joining API"
version:"1.0.0"
host:localhost:8008
schemes:
- https
- http
basePath:/_matrix/client/%CLIENT_MAJOR_VERSION%
consumes:
- application/json
produces:
- application/json
securityDefinitions:
$ref:definitions/security.yaml
paths:
# With an extra " " to disambiguate from the 3pid invite endpoint
# The extra space makes it sort first for what I'm sure is a good reason.
"/rooms/{roomId}/invite ":
post:
summary:Invite a user to participate in a particular room.
description:|-
.. _invite-by-user-id-endpoint:
*Notethat there are two forms of this API, which are documented separately.
This version of the API requires that the inviter knows the Matrix
identifier of the invitee. The other is documented in the*
`third party invites section`_.
This API invites a user to participate in a particular room.
They do not start participating in the room until they actually join the
room.
Only users currently in a particular room can invite other users to
join that room.
If the user was invited to the room, the homeserver will append a
``m.room.member`` event to the room.
.. _third party invites section:`invite-by-third-party-id-endpoint`_
operationId:inviteUser
security:
- accessToken:[]
parameters:
- in:path
type:string
name:roomId
description:The room identifier (not alias) to which to invite the user.
required:true
x-example:"!d41d8cd:matrix.org"
- in:body
name:body
required:true
schema:
type:object
example:{
"user_id": "@cheeky_monkey:matrix.org"
}
properties:
user_id:
type:string
description:The fully qualified user ID of the invitee.
required:["user_id"]
responses:
200:
description:The user has been invited to join the room.
examples:
application/json:{
}
schema:
type:object
400:
description:|-
The request is invalid. A meaningful ``errcode`` and description
error text will be returned. Example reasons for rejection include:
- The request body is malformed (``errcode`` set to ``M_BAD_JSON``
or ``M_NOT_JSON``).
- One or more users being invited to the room are residents of a
homeserver which does not support the requested room version. The
``errcode`` will be ``M_UNSUPPORTED_ROOM_VERSION`` in these cases.
schema:
"$ref": "definitions/errors/error.yaml"
403:
description:|-
You do not have permission to invite the user to the room. A meaningful ``errcode`` and description error text will be returned. Example reasons for rejections are:
- The invitee has been banned from the room.
- The invitee is already a member of the room.
- The inviter is not currently in the room.
- The inviter's power level is insufficient to invite users to the room.
examples:
application/json:{
"errcode": "M_FORBIDDEN", "error": "@cheeky_monkey:matrix.org is banned from the room"}
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
swagger:'2.0'
info:
title:"Matrix Client-Server Room Kicking API"
version:"1.0.0"
host:localhost:8008
schemes:
- https
- http
basePath:/_matrix/client/%CLIENT_MAJOR_VERSION%
consumes:
- application/json
produces:
- application/json
securityDefinitions:
$ref:definitions/security.yaml
paths:
"/rooms/{roomId}/kick":
post:
summary:Kick a user from the room.
description:|-
Kick a user from the room.
The caller must have the required power level in order to perform this operation.
Kicking a user adjusts the target member's membership state to be ``leave`` with an
optional ``reason``. Like with other membership changes, a user can directly adjust
the target member's state by making a request to ``/rooms/<room id>/state/m.room.member/<user id>``.
operationId:kick
security:
- accessToken:[]
parameters:
- in:path
type:string
name:roomId
description:The room identifier (not alias) from which the user should be kicked.
required:true
x-example:"!e42d8c:matrix.org"
- in:body
name:body
required:true
schema:
type:object
example:{
"reason": "Telling unfunny jokes",
"user_id": "@cheeky_monkey:matrix.org"
}
properties:
user_id:
type:string
description:The fully qualified user ID of the user being kicked.
reason:
type:string
description:|-
The reason the user has been kicked. This will be supplied as the
``reason`` on the target's updated `m.room.member`_ event.
required:["user_id"]
responses:
200:
description:The user has been kicked from the room.
examples:
application/json:{
}
schema:
type:object
403:
description:|-
You do not have permission to kick the user from the room. A meaningful ``errcode`` and description error text will be returned. Example reasons for rejections are:
- The kicker is not currently in the room.
- The kickee is not currently in the room.
- The kicker's power level is insufficient to kick users from the room.
examples:
application/json:{
"errcode": "M_FORBIDDEN",
"error": "You do not have a high enough power level to kick from this room."
You aren't a member of the room and weren't previously a
member of the room.
tags:
- Room participation
"/rooms/{roomId}/joined_members":
get:
summary:Gets the list of currently joined users and their profile data.
description:
This API returns a map of MXIDs to member info objects for members of the room. The current user must be in the room for it to work, unless it is an Application Service in which case any of the AS's users must be in the room.
This API is primarily for Application Services and should be faster to respond than ``/members`` as it can be implemented more efficiently on the server.
description:The room identifier (not alias) to which to invite the user.
required:true
x-example:"!d41d8cd:matrix.org"
- in:body
name:body
required:true
schema:
type:object
example:{
"id_server": "matrix.org",
"medium": "email",
"address": "cheeky@monkey.com"
}
properties:
id_server:
type:string
description:The hostname+port of the identity server which should be used for third party identifier lookups.
medium:
type:string
# TODO: Link to Identity Service spec when it eixsts
description:The kind of address being passed in the address field, for example ``email``.
address:
type:string
description:The invitee's third party identifier.
required:["id_server","medium","address"]
responses:
200:
description:The user has been invited to join the room.
examples:
application/json:{
}
schema:
type:object
403:
description:|-
You do not have permission to invite the user to the room. A meaningful ``errcode`` and description error text will be returned. Example reasons for rejections are:
- The invitee has been banned from the room.
- The invitee is already a member of the room.
- The inviter is not currently in the room.
- The inviter's power level is insufficient to invite users to the room.
examples:
application/json:{
"errcode": "M_FORBIDDEN", "error": "@cheeky_monkey:matrix.org is banned from the room"}
this._reset();this.initialize.apply(this,arguments);a&&this.reset(a,{silent:!0,parse:b.parse})};f.extend(r.prototype,k,{model:o,initialize:function(){},toJSON:function(a){returnthis.map(function(b){returnb.toJSON(a)})},add:function(a,b){varc,d,e,g,i,j={},k={},l=[];b||(b={});a=f.isArray(a)?a.slice():[a];c=0;for(d=a.length;c<d;c++){if(!(e=a[c]=this._prepareModel(a[c],b)))throwError("Can't add an invalid model to a collection");g=e.cid;i=e.id;j[g]||this._byCid[g]||null!=i&&(k[i]||this._byId[i])?
shift:function(a){varb=this.at(0);this.remove(b,a);returnb},get:function(a){returnnull==a?void0:this._byId[null!=a.id?a.id:a]},getByCid:function(a){returna&&this._byCid[a.cid||a]},at:function(a){returnthis.models[a]},where:function(a){returnf.isEmpty(a)?[]:this.filter(function(b){for(varcina)if(a[c]!==b.get(c))return!1;return!0})},sort:function(a){a||(a={});if(!this.comparator)throwError("Cannot sort a set without a comparator");varb=f.bind(this.comparator,this);1==this.comparator.length?
""},getFragment:function(a,b){if(null==a)if(this._hasPushState||b){vara=window.location.pathname,c=window.location.search;c&&(a+=c)}elsea=this.getHash();a.indexOf(this.options.root)||(a=a.substr(this.options.root.length));returna.replace(s,"")},start:function(a){if(m.started)throwError("Backbone.history has already been started");m.started=!0;this.options=f.extend({},{root:"/"},this.options,a);this._wantsHashChange=!1!==this.options.hashChange;this._wantsPushState=!!this.options.pushState;this._hasPushState=
for(varbina){varc=a[b];f.isFunction(c)||(c=this[a[b]]);if(!c)throwError('Method "'+a[b]+'" does not exist');vard=b.match(F),e=d[1],d=d[2],c=f.bind(c,this),e=e+(".delegateEvents"+this.cid);""===d?this.$el.bind(e,c):this.$el.delegate(d,e,c)}}},undelegateEvents:function(){this.$el.unbind(".delegateEvents"+this.cid)},_configure:function(a){this.options&&(a=f.extend({},this.options,a));for(varb=0,c=w.length;b<c;b++){vard=w[b];a[d]&&(this[d]=a[d])}this.options=a},_ensureElement:function(){if(this.el)this.setElement(this.el,
b,c){vard;d=b&&b.hasOwnProperty("constructor")?b.constructor:function(){a.apply(this,arguments)};f.extend(d,a);x.prototype=a.prototype;d.prototype=newx;b&&f.extend(d.prototype,b);c&&f.extend(d,c);d.prototype.constructor=d;d.__super__=a.prototype;returnd},n=function(a,b){return!a||!a[b]?null:f.isFunction(a[b])?a[b]():a[b]},t=function(){throwError('A "url" property or function must be specified');}}).call(this);
a.reduce===A){e&&(c=b.bind(c,e));returnf?a.reduce(c,d):a.reduce(c)}j(a,function(a,b,i){if(f)d=c.call(e,d,a,b,i);else{d=a;f=true}});if(!f)thrownewTypeError("Reduce of empty array with no initial value");returnd};b.reduceRight=b.foldr=function(a,c,d,e){varf=arguments.length>2;a==null&&(a=[]);if(B&&a.reduceRight===B){e&&(c=b.bind(c,e));returnf?a.reduceRight(c,d):a.reduceRight(c)}varg=b.toArray(a).reverse();e&&!f&&(c=b.bind(c,e));returnf?b.reduce(g,c,d,e):b.reduce(g,c)};b.find=b.detect=function(a,
description:The 3pid address of the user being looked up, matching the address requested.
medium:
type:string
description:A medium from the `3PID Types`_ Appendix, matching the medium requested.
mxid:
type:string
description:The Matrix user ID associated with the 3pid.
not_before:
type:integer
description:A unix timestamp before which the association is not known to be valid.
not_after:
type:integer
description:A unix timestamp after which the association is not known to be valid.
ts:
type:integer
description:The unix timestamp at which the association was verified.
signatures:
type:object
description:The signatures of the verifying identity servers which show that the association should be trusted, if you trust the verifying identity servers.
$ref:"../../schemas/server-signatures.yaml"
required:
- address
- medium
- mxid
- not_before
- not_after
- ts
- signatures
"/bulk_lookup":
post:
summary:Lookup Matrix user IDs for a list of 3pids.
description:Lookup Matrix user IDs for a list of 3pids.
operationId:lookupUsers
parameters:
- in:body
name:body
schema:
type:object
example:{
"threepids":
[
["email","user@example.org"],
["msisdn","123456789"],
["email","user2@example.org"]
]
}
properties:
threepids:
type:array
items:
type:array
title:3PID mappings
minItems:2
maxItems:2
items:
# TODO: Give real names to these values. Adding a `title` does not work.
#- type: 3PID Medium
#- type: 3PID Address
- type:string
- type:string
description:|-
An array of arrays containing the `3PID Types`_ with the ``medium``
in first position and the ``address`` in second position.
required:
- "threepids"
responses:
200:
description:A list of known 3PID mappings for the supplied 3PIDs.
examples:
application/json:{
"threepids": [
["email","user@example.org","@bla:example.org"],
["msisdn","123456789","@blah2:example.com"]
]
}
schema:
type:object
properties:
threepids:
type:array
items:
type:array
title:3PID mappings
minItems:3
maxItems:3
items:
# TODO: Give real names to these values. Adding a `title` does not work.
#- type: 3PID Medium
#- type: 3PID Address
#- type: Matrix User ID
- type:string
- type:string
- type:string
description:|-
An array of array containing the `3PID Types`_ with the ``medium``
in first position, the ``address`` in second position and Matrix user