Merge branch 'master' into travis/clarification/lowercasing
Travis Ralston
4 years ago
committed by
Richard van der Hoff
commit
21a132d3a5
@ -0,0 +1 @@
|
|||||||
|
Correct examples of `client_secret` request body parameters so that they do not include invalid characters.
|
||||||
@ -0,0 +1 @@
|
|||||||
|
The v1 identity service API has been removed in favour of the v2 API, as per [MSC2713](https://github.com/matrix-org/matrix-doc/pull/2713).
|
||||||
@ -0,0 +1,66 @@
|
|||||||
|
{
|
||||||
|
"Pin": "Rajszeg",
|
||||||
|
"Folder": "Mappa",
|
||||||
|
"Headphones": "Fejhallgató",
|
||||||
|
"Anchor": "Horgony",
|
||||||
|
"Bell": "Harang",
|
||||||
|
"Trumpet": "Trombita",
|
||||||
|
"Guitar": "Gitár",
|
||||||
|
"Ball": "Labda",
|
||||||
|
"Trophy": "Trófea",
|
||||||
|
"Rocket": "Rakáta",
|
||||||
|
"Aeroplane": "Repülő",
|
||||||
|
"Bicycle": "Kerékpár",
|
||||||
|
"Train": "Vonat",
|
||||||
|
"Flag": "Zászló",
|
||||||
|
"Telephone": "Telefon",
|
||||||
|
"Hammer": "Kalapács",
|
||||||
|
"Key": "Kulcs",
|
||||||
|
"Lock": "Lakat",
|
||||||
|
"Scissors": "Olló",
|
||||||
|
"Paperclip": "Gémkapocs",
|
||||||
|
"Pencil": "Ceruza",
|
||||||
|
"Book": "Könyv",
|
||||||
|
"Light Bulb": "Égő",
|
||||||
|
"Gift": "Ajándék",
|
||||||
|
"Clock": "Óra",
|
||||||
|
"Hourglass": "Homokóra",
|
||||||
|
"Umbrella": "Esernyő",
|
||||||
|
"Thumbs Up": "Hüvelykujj fel",
|
||||||
|
"Santa": "Télapó",
|
||||||
|
"Spanner": "Csavarkulcs",
|
||||||
|
"Glasses": "Szemüveg",
|
||||||
|
"Hat": "Kalap",
|
||||||
|
"Robot": "Robot",
|
||||||
|
"Smiley": "Mosoly",
|
||||||
|
"Heart": "Szív",
|
||||||
|
"Cake": "Süti",
|
||||||
|
"Pizza": "Pizza",
|
||||||
|
"Corn": "Kukorica",
|
||||||
|
"Strawberry": "Eper",
|
||||||
|
"Apple": "Alma",
|
||||||
|
"Banana": "Banán",
|
||||||
|
"Fire": "Tűz",
|
||||||
|
"Cloud": "Felhő",
|
||||||
|
"Moon": "Hold",
|
||||||
|
"Globe": "Földgömb",
|
||||||
|
"Mushroom": "Gomba",
|
||||||
|
"Cactus": "Kaktusz",
|
||||||
|
"Tree": "Fa",
|
||||||
|
"Flower": "Virág",
|
||||||
|
"Butterfly": "Pillangó",
|
||||||
|
"Octopus": "Polip",
|
||||||
|
"Fish": "Hal",
|
||||||
|
"Turtle": "Teknős",
|
||||||
|
"Penguin": "Pingvin",
|
||||||
|
"Rooster": "Kakas",
|
||||||
|
"Panda": "Panda",
|
||||||
|
"Rabbit": "Nyúl",
|
||||||
|
"Elephant": "Elefánt",
|
||||||
|
"Pig": "Malac",
|
||||||
|
"Unicorn": "Egyszarvú",
|
||||||
|
"Horse": "Ló",
|
||||||
|
"Lion": "Oroszlán",
|
||||||
|
"Cat": "Macska",
|
||||||
|
"Dog": "Kutya"
|
||||||
|
}
|
||||||
@ -1,302 +0,0 @@
|
|||||||
# Copyright 2018 New Vector Ltd
|
|
||||||
#
|
|
||||||
# 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 Identity Service Establishing Associations API"
|
|
||||||
version: "1.0.0"
|
|
||||||
host: localhost:8090
|
|
||||||
schemes:
|
|
||||||
- https
|
|
||||||
basePath: /_matrix/identity/api/v1
|
|
||||||
consumes:
|
|
||||||
- application/json
|
|
||||||
produces:
|
|
||||||
- application/json
|
|
||||||
paths:
|
|
||||||
"/3pid/getValidated3pid":
|
|
||||||
get:
|
|
||||||
summary: Check whether ownership of a 3pid was validated.
|
|
||||||
description: |-
|
|
||||||
Determines if a given 3pid has been validated by a user.
|
|
||||||
operationId: getValidated3pid
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: sid
|
|
||||||
description: The Session ID generated by the `requestToken` call.
|
|
||||||
required: true
|
|
||||||
x-example: 1234
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: client_secret
|
|
||||||
description: The client secret passed to the `requestToken` call.
|
|
||||||
required: true
|
|
||||||
x-example: monkeys_are_GREAT
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: Validation information for the session.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"medium": "email",
|
|
||||||
"validated_at": 1457622739026,
|
|
||||||
"address": "louise@bobs.burgers"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
medium:
|
|
||||||
type: string
|
|
||||||
description: The medium type of the 3pid.
|
|
||||||
address:
|
|
||||||
type: string
|
|
||||||
description: The address of the 3pid being looked up.
|
|
||||||
validated_at:
|
|
||||||
type: integer
|
|
||||||
description: |-
|
|
||||||
Timestamp, in milliseconds, indicating the time that the 3pid
|
|
||||||
was validated.
|
|
||||||
required: ['medium', 'address', 'validated_at']
|
|
||||||
400:
|
|
||||||
description: |-
|
|
||||||
The session has not been validated.
|
|
||||||
|
|
||||||
If the session has not been validated, then `errcode` will be
|
|
||||||
`M_SESSION_NOT_VALIDATED`. If the session has timed out, then
|
|
||||||
`errcode` will be `M_SESSION_EXPIRED`.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_SESSION_NOT_VALIDATED",
|
|
||||||
"error": "This validation session has not yet been completed"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
404:
|
|
||||||
description: The Session ID or client secret were not found.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_NO_VALID_SESSION",
|
|
||||||
"error": "No valid session was found matching that sid and client secret"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
"/3pid/bind":
|
|
||||||
post:
|
|
||||||
summary: Publish an association between a session and a Matrix user ID.
|
|
||||||
description: |-
|
|
||||||
Publish an association between a session and a Matrix user ID.
|
|
||||||
|
|
||||||
Future calls to `/lookup` for any of the session\'s 3pids will return
|
|
||||||
this association.
|
|
||||||
|
|
||||||
Note: for backwards compatibility with previous drafts of this
|
|
||||||
specification, the parameters may also be specified as
|
|
||||||
`application/x-form-www-urlencoded` data. However, this usage is
|
|
||||||
deprecated.
|
|
||||||
operationId: bind
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: body
|
|
||||||
name: body
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
example: {
|
|
||||||
"sid": "1234",
|
|
||||||
"client_secret": "monkeys_are_GREAT",
|
|
||||||
"mxid": "@ears:matrix.org"
|
|
||||||
}
|
|
||||||
properties:
|
|
||||||
sid:
|
|
||||||
type: string
|
|
||||||
description: The Session ID generated by the `requestToken` call.
|
|
||||||
client_secret:
|
|
||||||
type: string
|
|
||||||
description: The client secret passed to the `requestToken` call.
|
|
||||||
mxid:
|
|
||||||
type: string
|
|
||||||
description: The Matrix user ID to associate with the 3pids.
|
|
||||||
required: ["sid", "client_secret", "mxid"]
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: The association was published.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"address": "louise@bobs.burgers",
|
|
||||||
"medium": "email",
|
|
||||||
"mxid": "@ears:matrix.org",
|
|
||||||
"not_before": 1428825849161,
|
|
||||||
"not_after": 4582425849161,
|
|
||||||
"ts": 1428825849161,
|
|
||||||
"signatures": {
|
|
||||||
"matrix.org": {
|
|
||||||
"ed25519:0": "ENiU2YORYUJgE6WBMitU0mppbQjidDLanAusj8XS2nVRHPu+0t42OKA/r6zV6i2MzUbNQ3c3MiLScJuSsOiVDQ"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
address:
|
|
||||||
type: string
|
|
||||||
description: The 3pid address of the user being looked up.
|
|
||||||
medium:
|
|
||||||
type: string
|
|
||||||
description: The medium type of the 3pid.
|
|
||||||
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
|
|
||||||
services.
|
|
||||||
$ref: "../../schemas/server-signatures.yaml"
|
|
||||||
required:
|
|
||||||
- address
|
|
||||||
- medium
|
|
||||||
- mxid
|
|
||||||
- not_before
|
|
||||||
- not_after
|
|
||||||
- ts
|
|
||||||
- signatures
|
|
||||||
400:
|
|
||||||
description: |-
|
|
||||||
The association was not published.
|
|
||||||
|
|
||||||
If the session has not been validated, then `errcode` will be
|
|
||||||
`M_SESSION_NOT_VALIDATED`. If the session has timed out, then
|
|
||||||
`errcode` will be `M_SESSION_EXPIRED`.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_SESSION_NOT_VALIDATED",
|
|
||||||
"error": "This validation session has not yet been completed"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
404:
|
|
||||||
description: The Session ID or client secret were not found
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_NO_VALID_SESSION",
|
|
||||||
"error": "No valid session was found matching that sid and client secret"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
"/3pid/unbind":
|
|
||||||
post:
|
|
||||||
summary: Remove an association between a session and a Matrix user ID.
|
|
||||||
description: |-
|
|
||||||
Remove an association between a session and a Matrix user ID.
|
|
||||||
|
|
||||||
Future calls to `/lookup` for any of the session's 3pids will not
|
|
||||||
return the removed association.
|
|
||||||
|
|
||||||
The identity server should authenticate the request in one of two
|
|
||||||
ways:
|
|
||||||
|
|
||||||
1. The request is signed by the homeserver which controls the `user_id`.
|
|
||||||
2. The request includes the `sid` and `client_secret` parameters,
|
|
||||||
as per `/3pid/bind`, which proves ownership of the 3PID.
|
|
||||||
|
|
||||||
If this endpoint returns a JSON Matrix error, that error should be passed
|
|
||||||
through to the client requesting an unbind through a homeserver, if the
|
|
||||||
homeserver is acting on behalf of a client.
|
|
||||||
operationId: unbind
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: body
|
|
||||||
name: body
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
example: {
|
|
||||||
"sid": "1234",
|
|
||||||
"client_secret": "monkeys_are_GREAT",
|
|
||||||
"mxid": "@ears:example.org",
|
|
||||||
"threepid": {
|
|
||||||
"medium": "email",
|
|
||||||
"address": "monkeys_have_ears@example.org"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
properties:
|
|
||||||
sid:
|
|
||||||
type: string
|
|
||||||
description: The Session ID generated by the `requestToken` call.
|
|
||||||
client_secret:
|
|
||||||
type: string
|
|
||||||
description: The client secret passed to the `requestToken` call.
|
|
||||||
mxid:
|
|
||||||
type: string
|
|
||||||
description: The Matrix user ID to remove from the 3pids.
|
|
||||||
threepid:
|
|
||||||
type: object
|
|
||||||
title: 3PID
|
|
||||||
description: |-
|
|
||||||
The 3PID to remove. Must match the 3PID used to generate the session
|
|
||||||
if using `sid` and `client_secret` to authenticate this request.
|
|
||||||
properties:
|
|
||||||
medium:
|
|
||||||
type: string
|
|
||||||
description: |-
|
|
||||||
A medium from the [3PID Types](/appendices/#3pid-types) Appendix, matching the medium
|
|
||||||
of the identifier to unbind.
|
|
||||||
address:
|
|
||||||
type: string
|
|
||||||
description: The 3PID address to remove.
|
|
||||||
required: ['medium', 'address']
|
|
||||||
required: ["threepid", "mxid"]
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: The association was successfully removed.
|
|
||||||
examples:
|
|
||||||
application/json: {}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
400:
|
|
||||||
description: |-
|
|
||||||
If the response body is not a JSON Matrix error, the identity server
|
|
||||||
does not support unbinds. If a JSON Matrix error is in the response
|
|
||||||
body, the requesting party should respect the error.
|
|
||||||
404:
|
|
||||||
description: |-
|
|
||||||
If the response body is not a JSON Matrix error, the identity server
|
|
||||||
does not support unbinds. If a JSON Matrix error is in the response
|
|
||||||
body, the requesting party should respect the error.
|
|
||||||
403:
|
|
||||||
description: |-
|
|
||||||
The credentials supplied to authenticate the request were invalid.
|
|
||||||
This may also be returned if the identity server does not support
|
|
||||||
the chosen authentication method (such as blocking homeservers from
|
|
||||||
unbinding identifiers).
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_FORBIDDEN",
|
|
||||||
"error": "Invalid homeserver signature"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
501:
|
|
||||||
description: |-
|
|
||||||
If the response body is not a JSON Matrix error, the identity server
|
|
||||||
does not support unbinds. If a JSON Matrix error is in the response
|
|
||||||
body, the requesting party should respect the error.
|
|
||||||
@ -1,177 +0,0 @@
|
|||||||
# Copyright 2018 New Vector Ltd
|
|
||||||
#
|
|
||||||
# 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 Identity Service Email Associations API"
|
|
||||||
version: "1.0.0"
|
|
||||||
host: localhost:8090
|
|
||||||
schemes:
|
|
||||||
- https
|
|
||||||
basePath: /_matrix/identity/api/v1
|
|
||||||
consumes:
|
|
||||||
- application/json
|
|
||||||
produces:
|
|
||||||
- application/json
|
|
||||||
paths:
|
|
||||||
"/validate/email/requestToken":
|
|
||||||
post:
|
|
||||||
summary: Request a token for validating an email address.
|
|
||||||
description: |-
|
|
||||||
Create a session for validating an email address.
|
|
||||||
|
|
||||||
The identity server will send an email containing a token. If that
|
|
||||||
token is presented to the identity server in the future, it indicates
|
|
||||||
that that user was able to read the email for that email address, and
|
|
||||||
so we validate ownership of the email address.
|
|
||||||
|
|
||||||
Note that homeservers offer APIs that proxy this API, adding
|
|
||||||
additional behaviour on top, for example,
|
|
||||||
`/register/email/requestToken` is designed specifically for use when
|
|
||||||
registering an account and therefore will inform the user if the email
|
|
||||||
address given is already registered on the server.
|
|
||||||
|
|
||||||
Note: for backwards compatibility with previous drafts of this
|
|
||||||
specification, the parameters may also be specified as
|
|
||||||
`application/x-form-www-urlencoded` data. However, this usage is
|
|
||||||
deprecated.
|
|
||||||
operationId: emailRequestToken
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: body
|
|
||||||
name: body
|
|
||||||
schema:
|
|
||||||
$ref: "definitions/request_email_validation.yaml"
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: Session created.
|
|
||||||
schema:
|
|
||||||
$ref: "definitions/sid.yaml"
|
|
||||||
400:
|
|
||||||
description: |
|
|
||||||
An error ocurred. Some possible errors are:
|
|
||||||
|
|
||||||
- `M_INVALID_EMAIL`: The email address provided was invalid.
|
|
||||||
- `M_EMAIL_SEND_ERROR`: The validation email could not be sent.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_INVALID_EMAIL",
|
|
||||||
"error": "The email address is not valid"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
"/validate/email/submitToken":
|
|
||||||
post:
|
|
||||||
summary: Validate ownership of an email address.
|
|
||||||
description: |-
|
|
||||||
Validate ownership of an email address.
|
|
||||||
|
|
||||||
If the three parameters are consistent with a set generated by a
|
|
||||||
`requestToken` call, ownership of the email address is considered to
|
|
||||||
have been validated. This does not publish any information publicly, or
|
|
||||||
associate the email address with any Matrix user ID. Specifically,
|
|
||||||
calls to `/lookup` will not show a binding.
|
|
||||||
|
|
||||||
The identity server is free to match the token case-insensitively, or
|
|
||||||
carry out other mapping operations such as unicode
|
|
||||||
normalisation. Whether to do so is an implementation detail for the
|
|
||||||
identity server. Clients must always pass on the token without
|
|
||||||
modification.
|
|
||||||
|
|
||||||
Note: for backwards compatibility with previous drafts of this
|
|
||||||
specification, the parameters may also be specified as
|
|
||||||
`application/x-form-www-urlencoded` data. However, this usage is
|
|
||||||
deprecated.
|
|
||||||
operationId: emailSubmitTokenPost
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: body
|
|
||||||
name: body
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
example: {
|
|
||||||
"sid": "1234",
|
|
||||||
"client_secret": "monkeys_are_GREAT",
|
|
||||||
"token": "atoken"
|
|
||||||
}
|
|
||||||
properties:
|
|
||||||
sid:
|
|
||||||
type: string
|
|
||||||
description: The session ID, generated by the `requestToken` call.
|
|
||||||
client_secret:
|
|
||||||
type: string
|
|
||||||
description: The client secret that was supplied to the `requestToken` call.
|
|
||||||
token:
|
|
||||||
type: string
|
|
||||||
description: The token generated by the `requestToken` call and emailed to the user.
|
|
||||||
required: ["sid", "client_secret", "token"]
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description:
|
|
||||||
The success of the validation.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"success": true
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
success:
|
|
||||||
type: boolean
|
|
||||||
description: Whether the validation was successful or not.
|
|
||||||
required: ['success']
|
|
||||||
get:
|
|
||||||
summary: Validate ownership of an email address.
|
|
||||||
description: |-
|
|
||||||
Validate ownership of an email address.
|
|
||||||
|
|
||||||
If the three parameters are consistent with a set generated by a
|
|
||||||
`requestToken` call, ownership of the email address is considered to
|
|
||||||
have been validated. This does not publish any information publicly, or
|
|
||||||
associate the email address with any Matrix user ID. Specifically,
|
|
||||||
calls to `/lookup` will not show a binding.
|
|
||||||
|
|
||||||
Note that, in contrast with the POST version, this endpoint will be
|
|
||||||
used by end-users, and so the response should be human-readable.
|
|
||||||
operationId: emailSubmitTokenGet
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: sid
|
|
||||||
required: true
|
|
||||||
description: The session ID, generated by the `requestToken` call.
|
|
||||||
x-example: 1234
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: client_secret
|
|
||||||
required: true
|
|
||||||
description: The client secret that was supplied to the `requestToken` call.
|
|
||||||
x-example: monkeys_are_GREAT
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: token
|
|
||||||
required: true
|
|
||||||
description: The token generated by the `requestToken` call and emailed to the user.
|
|
||||||
x-example: atoken
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: Email address is validated.
|
|
||||||
"3xx":
|
|
||||||
description: |-
|
|
||||||
Email address is validated, and the `next_link` parameter was
|
|
||||||
provided to the `requestToken` call. The user must be redirected
|
|
||||||
to the URL provided by the `next_link` parameter.
|
|
||||||
"4xx":
|
|
||||||
description:
|
|
||||||
Validation failed.
|
|
||||||
@ -1,97 +0,0 @@
|
|||||||
# Copyright 2018 New Vector Ltd
|
|
||||||
#
|
|
||||||
# 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 Identity Service Ephemeral Invitation Signing API"
|
|
||||||
version: "1.0.0"
|
|
||||||
host: localhost:8090
|
|
||||||
schemes:
|
|
||||||
- https
|
|
||||||
basePath: /_matrix/identity/api/v1
|
|
||||||
consumes:
|
|
||||||
- application/json
|
|
||||||
produces:
|
|
||||||
- application/json
|
|
||||||
paths:
|
|
||||||
"/sign-ed25519":
|
|
||||||
post:
|
|
||||||
summary: Sign invitation details
|
|
||||||
description: |-
|
|
||||||
Sign invitation details.
|
|
||||||
|
|
||||||
The identity server will look up `token` which was stored in a call
|
|
||||||
to `store-invite`, and fetch the sender of the invite.
|
|
||||||
operationId: blindlySignStuff
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: body
|
|
||||||
name: body
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
example: {
|
|
||||||
"mxid": "@foo:bar.com",
|
|
||||||
"token": "sometoken",
|
|
||||||
"private_key": "base64encodedkey"
|
|
||||||
}
|
|
||||||
properties:
|
|
||||||
mxid:
|
|
||||||
type: string
|
|
||||||
description: The Matrix user ID of the user accepting the invitation.
|
|
||||||
token:
|
|
||||||
type: string
|
|
||||||
description: The token from the call to `store-invite`.
|
|
||||||
private_key:
|
|
||||||
type: string
|
|
||||||
description: The private key, encoded as [Unpadded base64](/appendices/#unpadded-base64).
|
|
||||||
required: ["mxid", "token", "private_key"]
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: The signed JSON of the mxid, sender, and token.
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
mxid:
|
|
||||||
type: string
|
|
||||||
description: The Matrix user ID of the user accepting the invitation.
|
|
||||||
sender:
|
|
||||||
type: string
|
|
||||||
description: The Matrix user ID of the user who sent the invitation.
|
|
||||||
signatures:
|
|
||||||
type: object
|
|
||||||
description: The signature of the mxid, sender, and token.
|
|
||||||
$ref: "../../schemas/server-signatures.yaml"
|
|
||||||
token:
|
|
||||||
type: string
|
|
||||||
description: The token for the invitation.
|
|
||||||
required: ['mxid', 'sender', 'signatures', 'token']
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"mxid": "@foo:bar.com",
|
|
||||||
"sender": "@baz:bar.com",
|
|
||||||
"signatures": {
|
|
||||||
"my.id.server": {
|
|
||||||
"ed25519:0": "def987"
|
|
||||||
}
|
|
||||||
},
|
|
||||||
"token": "abc123"
|
|
||||||
}
|
|
||||||
404:
|
|
||||||
description: The token was not found.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_UNRECOGNIZED",
|
|
||||||
"error": "Didn't recognize token"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
@ -1,171 +0,0 @@
|
|||||||
# Copyright 2016 OpenMarket Ltd
|
|
||||||
# Copyright 2017 Kamax.io
|
|
||||||
# Copyright 2017 New Vector Ltd
|
|
||||||
# Copyright 2018 New Vector Ltd
|
|
||||||
#
|
|
||||||
# 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 Identity Service Lookup API"
|
|
||||||
version: "1.0.0"
|
|
||||||
host: localhost:8090
|
|
||||||
schemes:
|
|
||||||
- https
|
|
||||||
basePath: /_matrix/identity/api/v1
|
|
||||||
consumes:
|
|
||||||
- application/json
|
|
||||||
produces:
|
|
||||||
- application/json
|
|
||||||
paths:
|
|
||||||
"/lookup":
|
|
||||||
get:
|
|
||||||
summary: Look up the Matrix user ID for a 3pid.
|
|
||||||
description: Look up the Matrix user ID for a 3pid.
|
|
||||||
operationId: lookupUser
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: medium
|
|
||||||
required: true
|
|
||||||
description: The medium type of the 3pid. See the [3PID Types](/appendices/#3pid-types) Appendix.
|
|
||||||
x-example: "email"
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: address
|
|
||||||
required: true
|
|
||||||
description: The address of the 3pid being looked up. See the [3PID Types](/appendices/#3pid-types) Appendix.
|
|
||||||
x-example: "louise@bobs.burgers"
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description:
|
|
||||||
The association for that 3pid, or an empty object if no association is known.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"address": "louise@bobs.burgers",
|
|
||||||
"medium": "email",
|
|
||||||
"mxid": "@ears:matrix.org",
|
|
||||||
"not_before": 1428825849161,
|
|
||||||
"not_after": 4582425849161,
|
|
||||||
"ts": 1428825849161,
|
|
||||||
"signatures": {
|
|
||||||
"matrix.org": {
|
|
||||||
"ed25519:0": "ENiU2YORYUJgE6WBMitU0mppbQjidDLanAusj8XS2nVRHPu+0t42OKA/r6zV6i2MzUbNQ3c3MiLScJuSsOiVDQ"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
address:
|
|
||||||
type: string
|
|
||||||
description: The 3pid address of the user being looked up, matching the address requested.
|
|
||||||
medium:
|
|
||||||
type: string
|
|
||||||
description: A medium from the [3PID Types](/appendices/#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
|
|
||||||
deprecated: true
|
|
||||||
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](/appendices/#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](/appendices/#3pid-types) with the `medium`
|
|
||||||
in first position, the `address` in second position and Matrix user
|
|
||||||
ID in third position.
|
|
||||||
required:
|
|
||||||
- "threepids"
|
|
||||||
@ -1,179 +0,0 @@
|
|||||||
# Copyright 2018 New Vector Ltd
|
|
||||||
#
|
|
||||||
# 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 Identity Service Phone Number Associations API"
|
|
||||||
version: "1.0.0"
|
|
||||||
host: localhost:8090
|
|
||||||
schemes:
|
|
||||||
- https
|
|
||||||
basePath: /_matrix/identity/api/v1
|
|
||||||
consumes:
|
|
||||||
- application/json
|
|
||||||
produces:
|
|
||||||
- application/json
|
|
||||||
paths:
|
|
||||||
"/validate/msisdn/requestToken":
|
|
||||||
post:
|
|
||||||
summary: Request a token for validating a phone number.
|
|
||||||
description: |-
|
|
||||||
Create a session for validating a phone number.
|
|
||||||
|
|
||||||
The identity server will send an SMS message containing a token. If
|
|
||||||
that token is presented to the identity server in the future, it
|
|
||||||
indicates that that user was able to read the SMS for that phone
|
|
||||||
number, and so we validate ownership of the phone number.
|
|
||||||
|
|
||||||
Note that homeservers offer APIs that proxy this API, adding
|
|
||||||
additional behaviour on top, for example,
|
|
||||||
`/register/msisdn/requestToken` is designed specifically for use when
|
|
||||||
registering an account and therefore will inform the user if the phone
|
|
||||||
number given is already registered on the server.
|
|
||||||
|
|
||||||
Note: for backwards compatibility with previous drafts of this
|
|
||||||
specification, the parameters may also be specified as
|
|
||||||
`application/x-form-www-urlencoded` data. However, this usage is
|
|
||||||
deprecated.
|
|
||||||
operationId: msisdnRequestToken
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: body
|
|
||||||
name: body
|
|
||||||
schema:
|
|
||||||
$ref: "definitions/request_msisdn_validation.yaml"
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: Session created.
|
|
||||||
schema:
|
|
||||||
$ref: "definitions/sid.yaml"
|
|
||||||
400:
|
|
||||||
description: |
|
|
||||||
An error ocurred. Some possible errors are:
|
|
||||||
|
|
||||||
- `M_INVALID_ADDRESS`: The phone number provided was invalid.
|
|
||||||
- `M_SEND_ERROR`: The validation SMS could not be sent.
|
|
||||||
- `M_DESTINATION_REJECTED`: The identity server cannot deliver an
|
|
||||||
SMS to the provided country or region.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_INVALID_ADDRESS",
|
|
||||||
"error": "The phone number is not valid"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
"/validate/msisdn/submitToken":
|
|
||||||
post:
|
|
||||||
summary: Validate ownership of a phone number.
|
|
||||||
description: |-
|
|
||||||
Validate ownership of a phone number.
|
|
||||||
|
|
||||||
If the three parameters are consistent with a set generated by a
|
|
||||||
`requestToken` call, ownership of the phone number is considered to
|
|
||||||
have been validated. This does not publish any information publicly, or
|
|
||||||
associate the phone number address with any Matrix user
|
|
||||||
ID. Specifically, calls to `/lookup` will not show a binding.
|
|
||||||
|
|
||||||
The identity server is free to match the token case-insensitively, or
|
|
||||||
carry out other mapping operations such as unicode
|
|
||||||
normalisation. Whether to do so is an implementation detail for the
|
|
||||||
identity server. Clients must always pass on the token without
|
|
||||||
modification.
|
|
||||||
|
|
||||||
Note: for backwards compatibility with previous drafts of this
|
|
||||||
specification, the parameters may also be specified as
|
|
||||||
`application/x-form-www-urlencoded` data. However, this usage is
|
|
||||||
deprecated.
|
|
||||||
operationId: msisdnSubmitTokenPost
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: body
|
|
||||||
name: body
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
example: {
|
|
||||||
"sid": "1234",
|
|
||||||
"client_secret": "monkeys_are_GREAT",
|
|
||||||
"token": "atoken"
|
|
||||||
}
|
|
||||||
properties:
|
|
||||||
sid:
|
|
||||||
type: string
|
|
||||||
description: The session ID, generated by the `requestToken` call.
|
|
||||||
client_secret:
|
|
||||||
type: string
|
|
||||||
description: The client secret that was supplied to the `requestToken` call.
|
|
||||||
token:
|
|
||||||
type: string
|
|
||||||
description: The token generated by the `requestToken` call and sent to the user.
|
|
||||||
required: ["sid", "client_secret", "token"]
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description:
|
|
||||||
The success of the validation.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"success": true
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
success:
|
|
||||||
type: boolean
|
|
||||||
description: Whether the validation was successful or not.
|
|
||||||
required: ['success']
|
|
||||||
get:
|
|
||||||
summary: Validate ownership of a phone number.
|
|
||||||
description: |-
|
|
||||||
Validate ownership of a phone number.
|
|
||||||
|
|
||||||
If the three parameters are consistent with a set generated by a
|
|
||||||
`requestToken` call, ownership of the phone number address is
|
|
||||||
considered to have been validated. This does not publish any
|
|
||||||
information publicly, or associate the phone number with any Matrix
|
|
||||||
user ID. Specifically, calls to `/lookup` will not show a binding.
|
|
||||||
|
|
||||||
Note that, in contrast with the POST version, this endpoint will be
|
|
||||||
used by end-users, and so the response should be human-readable.
|
|
||||||
operationId: msisdnSubmitTokenGet
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: sid
|
|
||||||
required: true
|
|
||||||
description: The session ID, generated by the `requestToken` call.
|
|
||||||
x-example: 1234
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: client_secret
|
|
||||||
required: true
|
|
||||||
description: The client secret that was supplied to the `requestToken` call.
|
|
||||||
x-example: monkeys_are_GREAT
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: token
|
|
||||||
required: true
|
|
||||||
description: The token generated by the `requestToken` call and sent to the user.
|
|
||||||
x-example: atoken
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: Phone number is validated.
|
|
||||||
"3xx":
|
|
||||||
description: |-
|
|
||||||
Phone number address is validated, and the `next_link` parameter
|
|
||||||
was provided to the `requestToken` call. The user must be
|
|
||||||
redirected to the URL provided by the `next_link` parameter.
|
|
||||||
"4xx":
|
|
||||||
description:
|
|
||||||
Validation failed.
|
|
||||||
@ -1,46 +0,0 @@
|
|||||||
# Copyright 2018 Kamax Sàrl
|
|
||||||
# Copyright 2018 New Vector Ltd
|
|
||||||
#
|
|
||||||
# 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 Identity Service Ping API"
|
|
||||||
version: "1.0.0"
|
|
||||||
host: localhost:8090
|
|
||||||
schemes:
|
|
||||||
- https
|
|
||||||
basePath: /_matrix/identity
|
|
||||||
produces:
|
|
||||||
- application/json
|
|
||||||
paths:
|
|
||||||
"/api/v1":
|
|
||||||
get:
|
|
||||||
summary: Checks that an identity server is available at this API endpoint.
|
|
||||||
description: |-
|
|
||||||
Checks that an identity server is available at this API endpoint.
|
|
||||||
|
|
||||||
To discover that an identity server is available at a specific URL,
|
|
||||||
this endpoint can be queried and will return an empty object.
|
|
||||||
|
|
||||||
This is primarly used for auto-discovery and health check purposes
|
|
||||||
by entities acting as a client for the identity server.
|
|
||||||
operationId: ping
|
|
||||||
deprecated: true
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: An identity server is ready to serve requests.
|
|
||||||
examples:
|
|
||||||
application/json: {}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
@ -1,129 +0,0 @@
|
|||||||
# Copyright 2016 OpenMarket Ltd
|
|
||||||
#
|
|
||||||
# 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 Identity Service Public Key API"
|
|
||||||
version: "1.0.0"
|
|
||||||
host: localhost:8090
|
|
||||||
schemes:
|
|
||||||
- https
|
|
||||||
basePath: /_matrix/identity/api/v1
|
|
||||||
consumes:
|
|
||||||
- application/json
|
|
||||||
produces:
|
|
||||||
- application/json
|
|
||||||
paths:
|
|
||||||
"/pubkey/{keyId}":
|
|
||||||
get:
|
|
||||||
summary: Get a public key.
|
|
||||||
description: |-
|
|
||||||
Get the public key for the passed key ID.
|
|
||||||
operationId: getPubKey
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: path
|
|
||||||
type: string
|
|
||||||
name: keyId
|
|
||||||
required: true
|
|
||||||
description: |-
|
|
||||||
The ID of the key. This should take the form algorithm:identifier
|
|
||||||
where algorithm identifies the signing algorithm, and the identifier
|
|
||||||
is an opaque string.
|
|
||||||
x-example: "ed25519:0"
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description:
|
|
||||||
The public key exists.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"public_key": "VXuGitF39UH5iRfvbIknlvlAVKgD1BsLDMvBf0pmp7c"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
public_key:
|
|
||||||
type: string
|
|
||||||
description: Unpadded Base64 encoded public key.
|
|
||||||
required: ['public_key']
|
|
||||||
404:
|
|
||||||
description:
|
|
||||||
The public key was not found.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_NOT_FOUND",
|
|
||||||
"error": "The public key was not found"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
"/pubkey/isvalid":
|
|
||||||
get:
|
|
||||||
summary: Check whether a long-term public key is valid.
|
|
||||||
description: |-
|
|
||||||
Check whether a long-term public key is valid. The response should always
|
|
||||||
be the same, provided the key exists.
|
|
||||||
operationId: isPubKeyValid
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: public_key
|
|
||||||
required: true
|
|
||||||
description: |-
|
|
||||||
The unpadded base64-encoded public key to check.
|
|
||||||
x-example: "VXuGitF39UH5iRfvbIknlvlAVKgD1BsLDMvBf0pmp7c"
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description:
|
|
||||||
The validity of the public key.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"valid": true
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
valid:
|
|
||||||
type: boolean
|
|
||||||
description: Whether the public key is recognised and is currently valid.
|
|
||||||
required: ['valid']
|
|
||||||
"/pubkey/ephemeral/isvalid":
|
|
||||||
get:
|
|
||||||
summary: Check whether a short-term public key is valid.
|
|
||||||
description: |-
|
|
||||||
Check whether a short-term public key is valid.
|
|
||||||
operationId: isEphemeralPubKeyValid
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: query
|
|
||||||
type: string
|
|
||||||
name: public_key
|
|
||||||
required: true
|
|
||||||
description: |-
|
|
||||||
The unpadded base64-encoded public key to check.
|
|
||||||
x-example: "VXuGitF39UH5iRfvbIknlvlAVKgD1BsLDMvBf0pmp7c"
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description:
|
|
||||||
The validity of the public key.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"valid": true
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
valid:
|
|
||||||
type: boolean
|
|
||||||
description: Whether the public key is recognised and is currently valid.
|
|
||||||
required: ['valid']
|
|
||||||
@ -1,161 +0,0 @@
|
|||||||
# Copyright 2018 New Vector Ltd
|
|
||||||
#
|
|
||||||
# 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 Identity Service Store Invitations API"
|
|
||||||
version: "1.0.0"
|
|
||||||
host: localhost:8090
|
|
||||||
schemes:
|
|
||||||
- https
|
|
||||||
basePath: /_matrix/identity/api/v1
|
|
||||||
consumes:
|
|
||||||
- application/json
|
|
||||||
produces:
|
|
||||||
- application/json
|
|
||||||
paths:
|
|
||||||
"/store-invite":
|
|
||||||
post:
|
|
||||||
summary: Store pending invitations to a user's 3pid.
|
|
||||||
description: |-
|
|
||||||
Store pending invitations to a user's 3pid.
|
|
||||||
|
|
||||||
In addition to the request parameters specified below, an arbitrary
|
|
||||||
number of other parameters may also be specified. These may be used in
|
|
||||||
the invite message generation described below.
|
|
||||||
|
|
||||||
The service will generate a random token and an ephemeral key used for
|
|
||||||
accepting the invite.
|
|
||||||
|
|
||||||
The service also generates a `display_name` for the inviter, which is
|
|
||||||
a redacted version of `address` which does not leak the full contents
|
|
||||||
of the `address`.
|
|
||||||
|
|
||||||
The service records persistently all of the above information.
|
|
||||||
|
|
||||||
It also generates an email containing all of this data, sent to the
|
|
||||||
`address` parameter, notifying them of the invitation.
|
|
||||||
|
|
||||||
Also, the generated ephemeral public key will be listed as valid on
|
|
||||||
requests to `/_matrix/identity/api/v1/pubkey/ephemeral/isvalid`.
|
|
||||||
|
|
||||||
Currently, invites may only be issued for 3pids of the `email` medium.
|
|
||||||
|
|
||||||
Optional fields in the request should be populated to the best of the
|
|
||||||
server's ability. Identity servers may use these variables when notifying
|
|
||||||
the `address` of the pending invite for display purposes.
|
|
||||||
operationId: storeInvite
|
|
||||||
deprecated: true
|
|
||||||
parameters:
|
|
||||||
- in: body
|
|
||||||
name: body
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
medium:
|
|
||||||
type: string
|
|
||||||
description: The literal string `email`.
|
|
||||||
example: "email"
|
|
||||||
address:
|
|
||||||
type: string
|
|
||||||
description: The email address of the invited user.
|
|
||||||
example: "foo@example.com"
|
|
||||||
room_id:
|
|
||||||
type: string
|
|
||||||
description: The Matrix room ID to which the user is invited
|
|
||||||
example: "!something:example.org"
|
|
||||||
sender:
|
|
||||||
type: string
|
|
||||||
description: The Matrix user ID of the inviting user
|
|
||||||
example: "@bob:example.com"
|
|
||||||
room_alias:
|
|
||||||
type: string
|
|
||||||
description: |-
|
|
||||||
The Matrix room alias for the room to which the user is
|
|
||||||
invited. This should be retrieved from the `m.room.canonical_alias`
|
|
||||||
state event.
|
|
||||||
example: "#somewhere:exmaple.org"
|
|
||||||
room_avatar_url:
|
|
||||||
type: string
|
|
||||||
description: |-
|
|
||||||
The Content URI for the room to which the user is invited. This should
|
|
||||||
be retrieved from the `m.room.avatar` state event.
|
|
||||||
example: "mxc://example.org/s0meM3dia"
|
|
||||||
room_join_rules:
|
|
||||||
type: string
|
|
||||||
description: |-
|
|
||||||
The `join_rule` for the room to which the user is invited. This should
|
|
||||||
be retrieved from the `m.room.join_rules` state event.
|
|
||||||
example: "public"
|
|
||||||
room_name:
|
|
||||||
type: string
|
|
||||||
description: |-
|
|
||||||
The name of the room to which the user is invited. This should be retrieved
|
|
||||||
from the `m.room.name` state event.
|
|
||||||
example: "Bob's Emporium of Messages"
|
|
||||||
sender_display_name:
|
|
||||||
type: string
|
|
||||||
description: The display name of the user ID initiating the invite.
|
|
||||||
example: "Bob Smith"
|
|
||||||
sender_avatar_url:
|
|
||||||
type: string
|
|
||||||
description: The Content URI for the avatar of the user ID initiating the invite.
|
|
||||||
example: "mxc://example.org/an0th3rM3dia"
|
|
||||||
required: ["medium", "address", "room_id", "sender"]
|
|
||||||
responses:
|
|
||||||
200:
|
|
||||||
description: The invitation was stored.
|
|
||||||
schema:
|
|
||||||
type: object
|
|
||||||
properties:
|
|
||||||
token:
|
|
||||||
type: string
|
|
||||||
description: |
|
|
||||||
The generated token. Must be a string consisting of the
|
|
||||||
characters `[0-9a-zA-Z.=_-]`. Its length must not exceed
|
|
||||||
255 characters and it must not be empty.
|
|
||||||
public_keys:
|
|
||||||
type: array
|
|
||||||
description: |
|
|
||||||
A list of [server's long-term public key, generated ephemeral
|
|
||||||
public key].
|
|
||||||
items:
|
|
||||||
type: string
|
|
||||||
display_name:
|
|
||||||
type: string
|
|
||||||
description: The generated (redacted) display_name.
|
|
||||||
required: ['token', 'public_keys', 'display_name']
|
|
||||||
example:
|
|
||||||
application/json: {
|
|
||||||
"token": "sometoken",
|
|
||||||
"public_keys": [
|
|
||||||
"serverpublickey",
|
|
||||||
"ephemeralpublickey"
|
|
||||||
],
|
|
||||||
"display_name": "f...@b..."
|
|
||||||
}
|
|
||||||
400:
|
|
||||||
description: |
|
|
||||||
An error has occured.
|
|
||||||
|
|
||||||
If the 3pid is already bound to a Matrix user ID, the error code
|
|
||||||
will be `M_THREEPID_IN_USE`. If the medium is unsupported, the
|
|
||||||
error code will be `M_UNRECOGNIZED`.
|
|
||||||
examples:
|
|
||||||
application/json: {
|
|
||||||
"errcode": "M_THREEPID_IN_USE",
|
|
||||||
"error": "Binding already known",
|
|
||||||
"mxid": "@alice:example.com"
|
|
||||||
}
|
|
||||||
schema:
|
|
||||||
$ref: "../client-server/definitions/errors/error.yaml"
|
|
||||||
@ -0,0 +1,427 @@
|
|||||||
|
# Proposal for Matrix "spaces" (formerly known as "groups as rooms (take 2)")
|
||||||
|
|
||||||
|
This MSC, and related proposals, supercede
|
||||||
|
[MSC1215](https://github.com/matrix-org/matrix-doc/issues/1215).
|
||||||
|
|
||||||
|
## Background and objectives
|
||||||
|
|
||||||
|
Collecting rooms together into groups is useful for a number of
|
||||||
|
purposes. Examples include:
|
||||||
|
|
||||||
|
* Allowing users to discover different rooms related to a particular topic:
|
||||||
|
for example "official matrix.org rooms".
|
||||||
|
* Allowing administrators to manage permissions across a number of rooms: for
|
||||||
|
example "a new employee has joined my company and needs access to all of our
|
||||||
|
rooms".
|
||||||
|
* Letting users classify their rooms: for example, separating "work" from
|
||||||
|
"personal" rooms.
|
||||||
|
|
||||||
|
We refer to such collections of rooms as "spaces".
|
||||||
|
|
||||||
|
Synapse and Element-Web currently implement an unspecced "groups" API (referred
|
||||||
|
to as "`/r0/groups`" in this document) which attempts to provide this
|
||||||
|
functionality (see
|
||||||
|
[MSC971](https://github.com/matrix-org/matrix-doc/issues/971)). However,
|
||||||
|
this is a complex API which has various problems (see
|
||||||
|
[appendix](#appendix-problems-with-the-r0groups-api)).
|
||||||
|
|
||||||
|
This proposal suggests a new approach where spaces are themselves represented
|
||||||
|
by rooms, rather than a custom first-class entity. This requires minimal
|
||||||
|
server changes.
|
||||||
|
|
||||||
|
The existing `/r0/groups` API would be deprecated in Synapse and remain
|
||||||
|
unspecified.
|
||||||
|
|
||||||
|
## Proposal
|
||||||
|
|
||||||
|
Each space is represented by its own room, known as a "space-room". The rooms
|
||||||
|
within the space are determined by state events within the space-room.
|
||||||
|
|
||||||
|
Space-rooms are distinguished from regular messaging rooms by the presence of
|
||||||
|
a `'type': 'm.space'` property in the content of the `m.room.create` event.
|
||||||
|
The value of the `type` property uses the Standardised Identifier Grammar from
|
||||||
|
[MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758). This allows clients to offer slightly customised user experience
|
||||||
|
depending on the purpose of the room. Currently, no server-side behaviour is
|
||||||
|
expected to depend on this property. A `type` property on the `m.room.create`
|
||||||
|
event is used to ensure that a room cannot change between being a space-room
|
||||||
|
and a non-space room. For more information, see the "Rejected Alternatives"
|
||||||
|
section below. Additionally, no client behaviour is recommended for handling
|
||||||
|
unknown room types given the potential for legacy data: clients are free to
|
||||||
|
make their own decisions about hiding unknown room types from users, though
|
||||||
|
should note that a future conversation-like type (for example) might be
|
||||||
|
introduced and could be considered "unknown" by older versions of their client.
|
||||||
|
|
||||||
|
As with regular rooms, public spaces are expected to have an alias, for example
|
||||||
|
`#foo:matrix.org`, which can be used to refer to the space.
|
||||||
|
|
||||||
|
Space-rooms may have `m.room.name`, `m.room.avatar` and `m.room.topic` state
|
||||||
|
events in the same way as a normal room.
|
||||||
|
|
||||||
|
Normal messages within a space-room are discouraged (but not blocked by the
|
||||||
|
server): user interfaces are not expected to have a way to enter or display
|
||||||
|
such messages. Space-rooms should be created with a power level for
|
||||||
|
`events_default` of 100, to prevent the rooms accidentally/maliciously
|
||||||
|
clogging up with messages from random members of the space.
|
||||||
|
|
||||||
|
### Membership of spaces
|
||||||
|
|
||||||
|
Users can be members of spaces (represented by `m.room.member` state events as
|
||||||
|
normal). The existing [`m.room.history_visibility`
|
||||||
|
mechanism](https://matrix.org/docs/spec/client_server/r0.6.1#room-history-visibility)
|
||||||
|
controls whether membership of the space is required to view the room list,
|
||||||
|
membership list, etc. "Public" or "community" spaces would be set to
|
||||||
|
`world_readable` to allow clients to see the directory of rooms within the
|
||||||
|
space by peeking into the space-room (thus avoiding the need to add
|
||||||
|
`m.room.member` events to the event graph within the room).
|
||||||
|
|
||||||
|
Join rules, invites and 3PID invites work as for a normal room. In order for
|
||||||
|
clients to distinguish space invites from room invites, all invites must now
|
||||||
|
include the `m.room.create` event in their `invite_state` and `knock_state`.
|
||||||
|
|
||||||
|
### Relationship between rooms and spaces
|
||||||
|
|
||||||
|
The intention is that rooms and spaces form a hierarchy, which clients can use
|
||||||
|
to structure the user's room list into a tree view. The parent/child
|
||||||
|
relationship can be expressed in one of two ways:
|
||||||
|
|
||||||
|
1. The admins of a space can advertise rooms and subspaces for their space by
|
||||||
|
setting `m.space.child` state events. The `state_key` is the ID of a child
|
||||||
|
room or space, and the content must contain a `via` key which gives a list
|
||||||
|
of candidate servers that can be used to join the room. Something like:
|
||||||
|
|
||||||
|
```jsonc
|
||||||
|
// a child room
|
||||||
|
{
|
||||||
|
"type": "m.space.child",
|
||||||
|
"state_key": "!abcd:example.com",
|
||||||
|
"content": {
|
||||||
|
"via": ["example.com", "test.org"]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
// a child room with an ordering.
|
||||||
|
{
|
||||||
|
"type": "m.space.child",
|
||||||
|
"state_key": "!efgh:example.com",
|
||||||
|
"content": {
|
||||||
|
"via": ["example.com"],
|
||||||
|
"order": "abcd"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
// no longer a child room
|
||||||
|
{
|
||||||
|
"type": "m.space.child",
|
||||||
|
"state_key": "!jklm:example.com",
|
||||||
|
"content": {}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Children where `via` is not present or invalid (not an array) are ignored.
|
||||||
|
|
||||||
|
The `order` key is a string which is used to provide a default ordering of
|
||||||
|
siblings in the room list. (Rooms are sorted based on a lexicographic
|
||||||
|
ordering of the Unicode codepoints of the characters in `order` values.
|
||||||
|
Rooms with no `order` come last, in ascending numeric order of the
|
||||||
|
`origin_server_ts` of their `m.room.create` events, or ascending
|
||||||
|
lexicographic order of their `room_id`s in case of equal
|
||||||
|
`origin_server_ts`. `order`s which are not strings, or do not consist
|
||||||
|
solely of ascii characters in the range `\x20` (space) to `\x7E` (`~`), or
|
||||||
|
consist of more than 50 characters, are forbidden and the field should be
|
||||||
|
ignored if received.)
|
||||||
|
|
||||||
|
2. Separately, rooms can claim parents via the `m.space.parent` state
|
||||||
|
event.
|
||||||
|
|
||||||
|
Similar to `m.space.child`, the `state_key` is the ID of the parent space,
|
||||||
|
and the content must contain a `via` key which gives a list of candidate
|
||||||
|
servers that can be used to join the parent.
|
||||||
|
|
||||||
|
```jsonc
|
||||||
|
{
|
||||||
|
"type": "m.space.parent",
|
||||||
|
"state_key": "!space:example.com",
|
||||||
|
"content": {
|
||||||
|
"via": ["example.com"],
|
||||||
|
"canonical": true
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Parents where `via` is not present or invalid (not an array) are ignored.
|
||||||
|
|
||||||
|
`canonical` determines whether this is the main parent for the space. When
|
||||||
|
a user joins a room with a canonical parent, clients may switch to view the
|
||||||
|
room in the context of that space, peeking into it in order to find other
|
||||||
|
rooms and group them together. In practice, well behaved rooms should only
|
||||||
|
have one `canonical` parent, but given this is not enforced: if multiple
|
||||||
|
are present the client should select the one with the lowest room ID, as
|
||||||
|
determined via a lexicographic ordering of the Unicode code-points.
|
||||||
|
|
||||||
|
To avoid abuse where a room admin falsely claims that a room is part of a
|
||||||
|
space that it should not be, clients could ignore such `m.space.parent`
|
||||||
|
events unless either (a) there is a corresponding `m.space.child` event in
|
||||||
|
the claimed parent, or (b) the sender of the `m.space.child` event has a
|
||||||
|
sufficient power-level to send such an `m.space.child` event in the
|
||||||
|
parent. (It is not necessarily required that that user currently be a
|
||||||
|
member of the parent room - only the `m.room.power_levels` event is
|
||||||
|
inspected.) [Checking the power-level rather than requiring an *actual*
|
||||||
|
`m.space.child` event in the parent allows for "secret" rooms (see below).]
|
||||||
|
|
||||||
|
Where the parent space also claims a parent, clients can recursively peek
|
||||||
|
into the grandparent space, and so on.
|
||||||
|
|
||||||
|
This structure means that rooms can end up appearing multiple times in the
|
||||||
|
room list hierarchy, given they can be children of multiple different spaces
|
||||||
|
(or have multiple parents in different spaces).
|
||||||
|
|
||||||
|
In a typical hierarchy, we expect *both* parent->child and child->parent
|
||||||
|
relationships to exist, so that the space can be discovered from the room, and
|
||||||
|
vice versa. Occasions when the relationship only exists in one direction
|
||||||
|
include:
|
||||||
|
|
||||||
|
* User-curated lists of rooms: in this case the space will not be listed as a
|
||||||
|
parent of the room.
|
||||||
|
|
||||||
|
* "Secret" rooms: rooms where the admin does not want the room to be
|
||||||
|
advertised as part of a given space, but *does* want the room to form part
|
||||||
|
of the hierarchy of that space for those in the know.
|
||||||
|
|
||||||
|
Cycles in the parent->child and child->parent relationships are *not*
|
||||||
|
permitted, but clients (and servers) should be aware that they may be
|
||||||
|
encountered, and MUST spot and break cycles rather than infinitely looping.
|
||||||
|
|
||||||
|
### Suggested children
|
||||||
|
|
||||||
|
Space admins can mark particular children of a space as "suggested". This
|
||||||
|
mainly serves as a hint to clients that that they can be displayed differently
|
||||||
|
(for example by showing them eagerly in the room list), though future
|
||||||
|
server-side interfaces (such as the summary API proposed in
|
||||||
|
[MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946)) might also
|
||||||
|
make use of it.
|
||||||
|
|
||||||
|
A suggested child is identified by a `"suggested": true` property in the
|
||||||
|
`m.space.child` event:
|
||||||
|
|
||||||
|
|
||||||
|
```jsonc
|
||||||
|
{
|
||||||
|
"type": "m.space.child",
|
||||||
|
"state_key": "!abcd:example.com",
|
||||||
|
"content": {
|
||||||
|
"via": ["example.com", "test.org"],
|
||||||
|
"suggested": true
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
A child which is missing the `suggested` property is treated identically to a
|
||||||
|
child with `"suggested": false`. A suggested child may be a room or a subspace.
|
||||||
|
|
||||||
|
### Extended "room invite state"
|
||||||
|
|
||||||
|
The specification is currently vague about what room state should be available
|
||||||
|
to users that have been invited to a room, though the Federation API spec does
|
||||||
|
recommend that the `invite_room_state` sent over federation via [PUT
|
||||||
|
`/_matrix/federation/v2/invite`](https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-invite-roomid-eventid)
|
||||||
|
should include "the join rules, canonical alias, avatar, and name of the room".
|
||||||
|
|
||||||
|
This MSC proposes adding `m.room.create` to that list, so that the recipient of
|
||||||
|
an invite can distinguish invites to spaces from other invites.
|
||||||
|
|
||||||
|
## Future extensions
|
||||||
|
|
||||||
|
The following sections are not blocking parts of this proposal, but are
|
||||||
|
included as a useful reference for how we imagine it will be extended in future.
|
||||||
|
|
||||||
|
### Auto-joined children
|
||||||
|
|
||||||
|
We could add an `auto_join` flag to `m.space.child` events to allow a space
|
||||||
|
admin to list the sub-spaces and rooms in that space which should be
|
||||||
|
automatically joined by members of that space.
|
||||||
|
|
||||||
|
This would be distinct from a force-join: the user could subsequently part any
|
||||||
|
auto-joined room if they desire.
|
||||||
|
|
||||||
|
Joining would be performed by the client. This could possibly be sped up by
|
||||||
|
using a summary API (such as that proposed in
|
||||||
|
[MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946)) to get a summary
|
||||||
|
of the spacetree to be joined, and then using a batch join API to join
|
||||||
|
whichever subset of it makes most sense for the client's UX.
|
||||||
|
|
||||||
|
Obviously auto-joining can be a DoS vector, and we consider it to be antisocial
|
||||||
|
for a space to try to autojoin its members to more than 100 children (in total).
|
||||||
|
|
||||||
|
Clients could display the auto-joined children in the room list whenever the
|
||||||
|
space appears in the list - thus helping users discover other rooms in a space
|
||||||
|
even if they're not joined to that space. For instance, if you join
|
||||||
|
`#matrix:matrix.org`, your client could show that room in the context of its
|
||||||
|
parent space, with that space's auto-joined children shown alongside it as
|
||||||
|
siblings.
|
||||||
|
|
||||||
|
### Restricting access to the spaces membership list
|
||||||
|
|
||||||
|
In the existing `/r0/groups` API, the group server has total control over the
|
||||||
|
visibility of group membership, as seen by a given querying user. In other
|
||||||
|
words, arbitrary users can see entirely different views of a group at the
|
||||||
|
server's discretion.
|
||||||
|
|
||||||
|
Whilst this is very powerful for mapping arbitrary organisational structures
|
||||||
|
into Matrix, it may be overengineered. Instead, the common case is (we believe)
|
||||||
|
a space where some users are publicly visible as members, and others are not.
|
||||||
|
|
||||||
|
One way of achieving this would be to create a separate space for the
|
||||||
|
private members - e.g. have `#foo:matrix.org` and `#foo-private:matrix.org`.
|
||||||
|
`#foo-private:matrix.org` is set up with `m.room.history_visibility` to not to
|
||||||
|
allow peeking; you have to be joined to see the members.
|
||||||
|
|
||||||
|
It's worth noting that any member of a space can currently see who else is a
|
||||||
|
member of that space, which might pose privacy problems for sensitive spaces.
|
||||||
|
While the server itself will inevitably track the space membership in state
|
||||||
|
events, a future MSC could restrict the membership from being sent to clients.
|
||||||
|
This is essentially the same as
|
||||||
|
[matrix-doc#1653](https://github.com/matrix-org/matrix-doc/issues/1653).
|
||||||
|
|
||||||
|
### Flair
|
||||||
|
|
||||||
|
("Flair" is a term we use to describe a small badge which appears next to a
|
||||||
|
user's displayname to advertise their membership of a space.)
|
||||||
|
|
||||||
|
The flair image for a group is given by the room avatar. (In future it might
|
||||||
|
preferable to use hand-crafted small resolution images: see
|
||||||
|
[matrix-doc#1778](https://github.com/matrix-org/matrix-doc/issues/1778).
|
||||||
|
|
||||||
|
One way this might be implemented is:
|
||||||
|
|
||||||
|
* User publishes the spaces they wish to announce on their profile
|
||||||
|
([MSC1769](https://github.com/matrix-org/matrix-doc/issues/1769)
|
||||||
|
as an `m.flair` state event: it lists the spaces which they are advertising.
|
||||||
|
|
||||||
|
* When a client wants to know the current flair for a set of users (i.e.
|
||||||
|
those which it is currently displaying in the timeline), it peeks the
|
||||||
|
profile rooms of those users. (Ideally there would be an API to support
|
||||||
|
peeking multiple rooms at once to facilitate this.)
|
||||||
|
|
||||||
|
* The client must check that the user is *actually* a member of the advertised
|
||||||
|
spaces. Nominally it can do this by peeking the membership list of the
|
||||||
|
space; however for efficiency we could expose a dedicated Client-Server API
|
||||||
|
to do this check (and both servers and clients can cache the results fairly
|
||||||
|
aggressively.)
|
||||||
|
|
||||||
|
## Related MSCs
|
||||||
|
|
||||||
|
* [MSC2946](https://github.com/matrix-org/matrix-doc/issues/2946): Spaces
|
||||||
|
Summary API.
|
||||||
|
|
||||||
|
* [MSC2962](https://github.com/matrix-org/matrix-doc/issues/2962): Managing
|
||||||
|
power levels via Spaces.
|
||||||
|
|
||||||
|
* [MSC3083](https://github.com/matrix-org/matrix-doc/issues/3083): Restricting
|
||||||
|
room membership based on space membership.
|
||||||
|
|
||||||
|
* [MSC2753](https://github.com/matrix-org/matrix-doc/issues/2753) for
|
||||||
|
effective peeking over the C/S API.
|
||||||
|
|
||||||
|
* [MSC2444](https://github.com/matrix-org/matrix-doc/issues/2444) (or similar)
|
||||||
|
for effective peeking over Federation.
|
||||||
|
|
||||||
|
## Security considerations
|
||||||
|
|
||||||
|
None at present.
|
||||||
|
|
||||||
|
## Potential issues
|
||||||
|
|
||||||
|
* If the membership of a space would be large (for example: an organisation of
|
||||||
|
several thousand people), this membership has to be copied entirely into the
|
||||||
|
room, rather than querying/searching incrementally.
|
||||||
|
|
||||||
|
* If the membership list is based on an external service such as LDAP, it is
|
||||||
|
hard to keep the space membership in sync with the LDAP directory. In
|
||||||
|
practice, it might be possible to do so via a nightly "synchronisation" job
|
||||||
|
which searches the LDAP directory, or via "AD auditing".
|
||||||
|
|
||||||
|
* No allowance is made for exposing different 'views' of the membership list to
|
||||||
|
different querying users. (It may be possible to simulate this behaviour
|
||||||
|
using smaller spaces).
|
||||||
|
|
||||||
|
* The requirement that `m.space.parent` links be ignored unless the sender has a
|
||||||
|
high PL in the parent room could lead to suprising effects where a parent
|
||||||
|
link suddenly ceases to take effect because a user loses their PL in the
|
||||||
|
parent room. This is mitigated in the general case by honouring the parent
|
||||||
|
link when there is a corresponding `m.space.child` event, however it remains
|
||||||
|
a problem for "secret" rooms.
|
||||||
|
|
||||||
|
* The `via` servers listed in the `m.space.child` and `m.space.parent` events
|
||||||
|
could get out of date, and will need to be updated from time to time. This
|
||||||
|
remains an unsolved problem.
|
||||||
|
|
||||||
|
## Rejected alternatives
|
||||||
|
|
||||||
|
### Use a separate state event for type of room
|
||||||
|
|
||||||
|
[MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840) proposes the use
|
||||||
|
of a separate `m.room.type` state event to distinguish different room types.
|
||||||
|
This implies that rooms can dynamically switch between being a Space, and
|
||||||
|
being a regular non-Space room. That is not a usecase we consider useful, and
|
||||||
|
allowing it would impose significant complexity on client and server
|
||||||
|
implementations. Specifically, client and server implementations who store
|
||||||
|
spaces separately from rooms would have to support migrating back and forth
|
||||||
|
between them and dealing with the ambiguities of `room_id`s no longer pointing
|
||||||
|
to valid spaces, etc.
|
||||||
|
|
||||||
|
### Use a different sigil/twigil for spaces
|
||||||
|
|
||||||
|
Groups used + as a sigil to differentiate them from rooms (e.g. +matrix:matrix.org).
|
||||||
|
We considered doing similar for Spaces, e.g. a #+ twigil or reuse the + sigil,
|
||||||
|
but concluded that the resulting complexity and exoticism is not worth it.
|
||||||
|
This means that clients such as matrix.to have to peek into rooms to find out their
|
||||||
|
`type` before being able to display an appropriate UI, and users will not know
|
||||||
|
whether #matrix:matrix.org is a room or a space without using a client (e.g. if
|
||||||
|
reading an advert). It also means that if the client UI requires a space alias the
|
||||||
|
client will need to validate the entered data serverside.
|
||||||
|
|
||||||
|
## Unstable prefix
|
||||||
|
|
||||||
|
The following mapping will be used for identifiers in this MSC during
|
||||||
|
development:
|
||||||
|
|
||||||
|
Proposed final identifier | Purpose | Development identifier
|
||||||
|
------------------------------- | ------- | ----
|
||||||
|
`type` | property in `m.room.create` | `org.matrix.msc1772.type`
|
||||||
|
`m.space` | value of `type` in `m.room.create` | `org.matrix.msc1772.space`
|
||||||
|
`m.space.child` | event type | `org.matrix.msc1772.space.child`
|
||||||
|
`m.space.parent` | event type | `org.matrix.msc1772.space.parent`
|
||||||
|
|
||||||
|
## History
|
||||||
|
|
||||||
|
* This replaces [MSC1215](https://docs.google.com/document/d/1ZnAuA_zti-K2-RnheXII1F1-oyVziT4tJffdw1-SHrE).
|
||||||
|
* Other thoughts that led into this are [documented](https://docs.google.com/document/d/1hljmD-ytdCRL37t-D_LvGDA3a0_2MwowSPIiZRxcabs).
|
||||||
|
|
||||||
|
## Appendix: problems with the `/r0/groups` API
|
||||||
|
|
||||||
|
The existing `/r0/groups` API, as proposed in
|
||||||
|
[MSC971](https://github.com/matrix-org/matrix-doc/issues/971), has various
|
||||||
|
problems, including:
|
||||||
|
|
||||||
|
* It is a large API surface to implement, maintain and spec - particularly for
|
||||||
|
all the different clients out there.
|
||||||
|
* Much of the API overlaps significantly with mechanisms we already have for
|
||||||
|
managing rooms:
|
||||||
|
* Tracking membership identity
|
||||||
|
* Tracking membership hierarchy
|
||||||
|
* Inviting/kicking/banning user
|
||||||
|
* Tracking key/value metadata
|
||||||
|
* There are membership management features which could benefit rooms which
|
||||||
|
would also benefit groups and vice versa (e.g. "auditorium mode")
|
||||||
|
* The current implementations on Riot Web/iOS/Android all suffer bugs and
|
||||||
|
issues which have been solved previously for rooms.
|
||||||
|
* no local-echo of invites
|
||||||
|
* failures to set group avatars
|
||||||
|
* ability to specify multiple admins
|
||||||
|
* It doesn't support pushing updates to clients (particularly for flair
|
||||||
|
membership): https://github.com/vector-im/riot-web/issues/5235
|
||||||
|
* It doesn't support third-party invites.
|
||||||
|
* Groups could benefit from other features which already exist today for rooms
|
||||||
|
* e.g. Room Directories
|
||||||
|
* Groups are centralised, rather than being replicated across all
|
||||||
|
participating servers.
|
||||||
@ -0,0 +1,40 @@
|
|||||||
|
# MSC3122: Deprecate starting key verifications without requesting first
|
||||||
|
|
||||||
|
Currently, the [Key verification
|
||||||
|
framework](https://spec.matrix.org/unstable/client-server-api/#key-verification-framework)
|
||||||
|
allows a device to begin a verification via to-device messages by sending an
|
||||||
|
`m.key.verification.start` event without first sending or receiving an
|
||||||
|
`m.key.verification.request` message. (The last sentence of the 5th paragraph
|
||||||
|
of the Key verification framework in the unstable spec, as of the time of
|
||||||
|
writing.) However, doing so does not provide a good user experience, and
|
||||||
|
allowing this adds unnecessary complexity to implementations.
|
||||||
|
|
||||||
|
We propose to deprecate allowing this behaviour.
|
||||||
|
|
||||||
|
Note that verifications in DMs do not allow this behaviour. Currently, Element
|
||||||
|
Web is the only client known to do this.
|
||||||
|
|
||||||
|
## Proposal
|
||||||
|
|
||||||
|
The ability to begin a key verification by sending an
|
||||||
|
`m.key.verification.start` event as a to-device event without a prior
|
||||||
|
`m.key.verification.request` is deprecated. New clients should not begin
|
||||||
|
verifications in this way, but will still need to accept verifications begun in
|
||||||
|
this way, until it is removed from the spec.
|
||||||
|
|
||||||
|
## Potential issues
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
|
||||||
|
We could do nothing and leave it in the spec. But we should clean up cruft when
|
||||||
|
possible.
|
||||||
|
|
||||||
|
## Security considerations
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
## Unstable prefix
|
||||||
|
|
||||||
|
No unstable prefix is required since we are simply deprecating behaviour.
|
||||||
Loading…
Reference in New Issue