matrix-spec-proposals

Commit Graph

Author	SHA1	Message	Date
Travis Ralston	a3364ff357	Spec SAS verification and the common key verification framework Reference implementations: * `94f664e725` * https://github.com/matrix-org/matrix-react-sdk/pull/2461 * https://github.com/matrix-org/matrix-js-sdk/pull/818 * https://github.com/matrix-org/matrix-react-sdk/pull/2596 * https://github.com/matrix-org/matrix-js-sdk/pull/837 Proposals: * [MSC1717](https://github.com/matrix-org/matrix-doc/pull/1717) * [MSC1267](https://github.com/matrix-org/matrix-doc/issues/1267) No alterations to either proposal have been made intentionally here.	5 years ago
Travis Ralston	d6d74c4cbe	Switch to using $ instead of # for sub-types # is reserved by the swagger validator as a way to include partial content from a JSON object (eg: "#/path" would include {"test": true} from the object {"path":{"test":true}}). Instead of trying to convince the validator that it is wrong, we'll just use a different character. Note that our rendering tools do not care about #-style references to objects. It's still somewhat worth changing the character though.	5 years ago
Travis Ralston	5eea4a477f	Add server notices support As per [MSC1452](https://github.com/matrix-org/matrix-doc/issues/1452) Fixes https://github.com/matrix-org/matrix-doc/issues/1254 Although MSC1452 focuses on just the warnings part of the server notices, the base for notices has not been established in the spec. This commit adds the needed support to be able to handle notices. No intentional divergences from the proposal are included in this changeset. There are a few additions which are used in practice although not defined in the proposal, such as who is responsible for aesthetics, sending notices, and other misc rules.	5 years ago
Travis Ralston	76946a8a7c	Simplify changelog generation We don'e need `{{server_server_changelog_r0.1.0}}` (for example), so don't go through the hassle of generating it. Instead, we'll generate the changelog for the requested versions of each API and put that in place. In the future, we may wish to consider bringing back more complicated variables when/if we start generating released versions of the spec on the fly rather than manually.	5 years ago
Travis Ralston	54ee861b5f	Fix changelog generation for non-default versions Currently if you generate a changelog for r0.1.1 of an API, you'd get "No significant changes" which is wrong. You should get a real changelog for the version. This is now handled by generating a "preferred" changelog which acts as the default for version variables in the RST. Using a specific version's changelog is still supported for the rare cases where that is desired.	6 years ago
Travis Ralston	ffe577371d	Add a room version specification The "Room Specification" (or "Room Version Specification") is the specification that defines which room versions do what and are intended to be documents which speak the truth about how rooms operate under the hood. The approach taken here is a bit different than other specifications. For starters, the specification is versioned in this project instead of relying on the matrix.org repository to track compiled HTML. This is done for a couple reasons, the first being we're still developing the v1 specification while concurrently making a v2 spec and the second being trying to reduce the reliance on matrix.org's repository for specifications. Because the room spec is built into versions, some changes needed to be made. The `targets.yaml` now has a special syntax for indicating what version something is at, and the changelog generator can handle rendering different versions of the same changelog (as parsed from the RST). Some additional work has been put in to the changelog parsing to allow us to reference the v1 room spec as "v1" without having to sacrifice clarity in the changelog headings. Finally, this moves the state resolution algorithms into the versioned spec as a result of MSC1759 (https://github.com/matrix-org/matrix-doc/pull/1759). Note: this does not introduce the concept of versioned schemas (tabs) that I was previously working with. There's currently no use for them, so they are shelved elsewhere.	6 years ago
Travis Ralston	7d34995ece	It's actually an "identity server implementing the Identity Service API" Also add a note about appservices being special.	6 years ago
Travis Ralston	7ac76fa27c	Actually we're going with "identity server" afterall	6 years ago
Travis Ralston	98a445890c	Render a warning if the spec is unstable Fixes https://github.com/matrix-org/matrix-doc/issues/1499 This is done by using magic variables in the RST. The magic variables are generated based on the substitutions available, making them available for use at build-time. Magic variables were chosen because it allows people to continue working on the spec and release process without having to worry about removing a chunk of text from the top of the file. Originally, this was attempted by using jinja2 if-statements, however the substitutions are replaced after the template is executed, so the condition would never match. The format of the variable is to make the templating happy. Using colons or percent signs results in the templator thinking something else is going on, and then complaining about format.	6 years ago
Travis Ralston	2753d24302	Merge remote-tracking branch 'matrix-org/master' into travis/general/r0-prep	6 years ago
Travis Ralston	a5c3924492	Merge remote matrix-org/master	6 years ago
Travis Ralston	e7a69a6a6d	Merge remote-tracking branch 'matrix-org/master' into travis/general/r0-prep	6 years ago
Travis Ralston	fa96d8629b	Prepare the appservice spec for an r0 release This puts the scaffolding in place for an r0 release to happen, such as the changelog and version variables.	6 years ago
Travis Ralston	d370a2c6fd	Prepare the identity service and server-server APIs for r0 * Create the changelog scaffolding * Set up the variables for versioning	6 years ago
Travis Ralston	ba51d5960e	r0.1.0 release of the Push Gateway specification Because this is the first release, it has several moving parts to it: * The version variables have been defined. * The towncrier changelog has been prepared for future modifications. * The templating has been updated to better support future versions of the specification. * A release process document has been created.	6 years ago
Travis Ralston	ea307b5bdb	Support rendering schema definitions in the spec	6 years ago
Richard van der Hoff	a38d4fc68e	Move templating into scripts dir There's no real need for this to be at the top level.	7 years ago

17 Commits (85003eb7845e5ebfda28449225f7e42525a88538)