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.
* 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
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>
* 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>
* 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>
* 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
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.
* 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>
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.
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>
* 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
* 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
* 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
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>
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.
Denis Kasak