Merge branch 'master' into daniel/multipleexamples
Conflicts: specification/modules/third_party_invites.rstpull/977/head
commit
2734f9f9f2
@ -0,0 +1,127 @@
|
|||||||
|
swagger: '2.0'
|
||||||
|
info:
|
||||||
|
title: "Matrix Client-Server v1 Room Membership API for third party identifiers"
|
||||||
|
version: "1.0.0"
|
||||||
|
host: localhost:8008
|
||||||
|
schemes:
|
||||||
|
- https
|
||||||
|
- http
|
||||||
|
basePath: /_matrix/client/api/v1
|
||||||
|
consumes:
|
||||||
|
- application/json
|
||||||
|
produces:
|
||||||
|
- application/json
|
||||||
|
securityDefinitions:
|
||||||
|
accessToken:
|
||||||
|
type: apiKey
|
||||||
|
description: The user_id or application service access_token
|
||||||
|
name: access_token
|
||||||
|
in: query
|
||||||
|
paths:
|
||||||
|
"/rooms/{roomId}/invite":
|
||||||
|
post:
|
||||||
|
summary: Invite a user to participate in a particular room.
|
||||||
|
description: |-
|
||||||
|
.. _invite-by-third-party-id-endpoint:
|
||||||
|
|
||||||
|
*Note that there are two forms of this API, which are documented separately.
|
||||||
|
This version of the API does not require that the inviter know the Matrix
|
||||||
|
identifier of the invitee, and instead relies on third party identifiers.
|
||||||
|
The homeserver uses an identity server to perform the mapping from
|
||||||
|
third party identifier to a Matrix identifier. The other is documented in the*
|
||||||
|
`joining rooms section`_.
|
||||||
|
|
||||||
|
This API invites a user to participate in a particular room.
|
||||||
|
They do not start participating in the room until they actually join the
|
||||||
|
room.
|
||||||
|
|
||||||
|
Only users currently in a particular room can invite other users to
|
||||||
|
join that room.
|
||||||
|
|
||||||
|
If the identity server did know the Matrix user identifier for the
|
||||||
|
third party identifier, the home server will append a ``m.room.member``
|
||||||
|
event to the room.
|
||||||
|
|
||||||
|
If the identity server does not know a Matrix user identifier for the
|
||||||
|
passed third party identifier, the homeserver will issue an invitation
|
||||||
|
which can be accepted upon providing proof of ownership of the third
|
||||||
|
party identifier. This is achieved by the identity server generating a
|
||||||
|
token, which it gives to the inviting homeserver. The homeserver will
|
||||||
|
add an ``m.room.third_party_invite`` event into the graph for the room,
|
||||||
|
containing that token.
|
||||||
|
|
||||||
|
When the invitee binds the invited third party identifier to a Matrix
|
||||||
|
user ID, the identity server will give the user a list of pending
|
||||||
|
invitations, each containing:
|
||||||
|
|
||||||
|
- The room ID to which they were invited
|
||||||
|
|
||||||
|
- The token given to the homeserver
|
||||||
|
|
||||||
|
- A signature of the token, signed with the identity server's private key
|
||||||
|
|
||||||
|
- The matrix user ID who invited them to the room
|
||||||
|
|
||||||
|
If a token is requested from the identity server, the home server will
|
||||||
|
append a ``m.room.third_party_invite`` event to the room.
|
||||||
|
|
||||||
|
.. _joining rooms section: `invite-by-user-id-endpoint`_
|
||||||
|
security:
|
||||||
|
- accessToken: []
|
||||||
|
parameters:
|
||||||
|
- in: path
|
||||||
|
type: string
|
||||||
|
name: roomId
|
||||||
|
description: The room identifier (not alias) to which to invite the user.
|
||||||
|
required: true
|
||||||
|
x-example: "!d41d8cd:matrix.org"
|
||||||
|
- in: body
|
||||||
|
name: body
|
||||||
|
required: true
|
||||||
|
schema:
|
||||||
|
type: object
|
||||||
|
example: |-
|
||||||
|
{
|
||||||
|
"id_server": "matrix.org",
|
||||||
|
"medium": "email",
|
||||||
|
"address": "cheeky@monkey.com",
|
||||||
|
"display_name": "A very cheeky monkey"
|
||||||
|
}
|
||||||
|
properties:
|
||||||
|
id_server:
|
||||||
|
type: string
|
||||||
|
description: The hostname+port of the identity server which should be used for third party identifier lookups.
|
||||||
|
medium:
|
||||||
|
type: string
|
||||||
|
# TODO: Link to identity service spec when it eixsts
|
||||||
|
description: The kind of address being passed in the address field, for example ``email``.
|
||||||
|
address:
|
||||||
|
type: string
|
||||||
|
description: The invitee's third party identifier.
|
||||||
|
display_name:
|
||||||
|
type: string
|
||||||
|
description: A user-friendly string describing who has been invited. It should not contain the address of the invitee, to avoid leaking mappings between third party identities and matrix user IDs.
|
||||||
|
required: ["id_server", "medium", "address", "display_name"]
|
||||||
|
responses:
|
||||||
|
200:
|
||||||
|
description: The user has been invited to join the room.
|
||||||
|
examples:
|
||||||
|
application/json: |-
|
||||||
|
{}
|
||||||
|
schema:
|
||||||
|
type: object
|
||||||
|
403:
|
||||||
|
description: |-
|
||||||
|
You do not have permission to invite the user to the room. A meaningful ``errcode`` and description error text will be returned. Example reasons for rejections are:
|
||||||
|
|
||||||
|
- The invitee has been banned from the room.
|
||||||
|
- The invitee is already a member of the room.
|
||||||
|
- The inviter is not currently in the room.
|
||||||
|
- The inviter's power level is insufficient to invite users to the room.
|
||||||
|
examples:
|
||||||
|
application/json: |-
|
||||||
|
{"errcode": "M_FORBIDDEN", "error": "@cheeky_monkey:matrix.org is banned from the room"}
|
||||||
|
429:
|
||||||
|
description: This request was rate-limited.
|
||||||
|
schema:
|
||||||
|
"$ref": "definitions/error.yaml"
|
@ -1,6 +1,16 @@
|
|||||||
pre.code .comment, code .comment { color: green }
|
pre.code .comment, code .comment { color: green }
|
||||||
pre.code .keyword, code .keyword { color: darkred; font-weight: bold }
|
pre.code .keyword, code .keyword { color: darkred; font-weight: bold }
|
||||||
pre.code .name.builtin, code .name.builtin { color: darkred; font-weight: bold }
|
pre.code .name.builtin, code .name.builtin { color: darkred; font-weight: bold }
|
||||||
pre.code .literal.number, code .literal.number { color: blue }
|
|
||||||
pre.code .name.tag, code .name.tag { color: darkgreen }
|
pre.code .name.tag, code .name.tag { color: darkgreen }
|
||||||
pre.code .literal.string, code .literal.string { color: darkblue }
|
pre.code .literal, code .literal { color: darkblue }
|
||||||
|
pre.code .literal.number, code .literal.number { color: blue }
|
||||||
|
|
||||||
|
|
||||||
|
/* HTTP Methods have class "name function" */
|
||||||
|
pre.code.http .name.function, code.http .name.function { color: black; font-weight: bold }
|
||||||
|
/* HTTP Paths have class "name namespace" */
|
||||||
|
pre.code.http .name.namespace, code.http .name.namespace { color: darkgreen }
|
||||||
|
/* HTTP "HTTP" strings have class "keyword reserved" */
|
||||||
|
pre.code.http .keyword.reserved, code.http .keyword.reserved { color: black; font-weight: bold }
|
||||||
|
/* HTTP Header names have class "name attribute" */
|
||||||
|
pre.code.http .name.attribute, code.http .name.attribute { color: black; font-weight: bold }
|
||||||
|
@ -0,0 +1,50 @@
|
|||||||
|
Guest access
|
||||||
|
================
|
||||||
|
|
||||||
|
.. _module:guest-access:
|
||||||
|
|
||||||
|
It may be desirable to allow users without a fully registered user account to
|
||||||
|
ephemerally access Matrix rooms. This module specifies limited ways of doing so.
|
||||||
|
|
||||||
|
Note that this is not currently a complete anonymous access solution; in
|
||||||
|
particular, it only allows servers to provided anonymous access to rooms in
|
||||||
|
which they are already participating, and relies on individual homeservers to
|
||||||
|
adhere to the conventions which this module sets, rather than allowing all
|
||||||
|
participating homeservers to enforce them.
|
||||||
|
|
||||||
|
Events
|
||||||
|
------
|
||||||
|
|
||||||
|
{{m_room_guest_accessibility}}
|
||||||
|
|
||||||
|
Client behaviour
|
||||||
|
----------------
|
||||||
|
A client can register for guest access using the FOO endpoint. From that point
|
||||||
|
on, they can interact with a limited subset of the existing client-server API,
|
||||||
|
as if they were a fully registered user, using the access token granted to them
|
||||||
|
by the server.
|
||||||
|
|
||||||
|
These users are only allowed to make calls in relation to rooms which have the
|
||||||
|
``m.room.history_visibility`` event set to ``world_readable``.
|
||||||
|
|
||||||
|
The APIs they are allowed to hit are:
|
||||||
|
|
||||||
|
/rooms/{roomId}/messages
|
||||||
|
/rooms/{roomId}/state
|
||||||
|
/rooms/{roomId}/state/{eventType}/{stateKey}
|
||||||
|
/events
|
||||||
|
|
||||||
|
Server behaviour
|
||||||
|
----------------
|
||||||
|
Does the server need to handle any of the new events in a special way (e.g.
|
||||||
|
typing timeouts, presence). Advice on how to persist events and/or requests are
|
||||||
|
recommended to aid implementation. Federation-specific logic should be included
|
||||||
|
here.
|
||||||
|
|
||||||
|
Security considerations
|
||||||
|
-----------------------
|
||||||
|
This includes privacy leaks: for example leaking presence info. How do
|
||||||
|
misbehaving clients or servers impact this module? This section should always be
|
||||||
|
included, if only to say "we've thought about it but there isn't anything to do
|
||||||
|
here".
|
||||||
|
|
Loading…
Reference in New Issue