diff --git a/docs/client-server/howto.rst b/docs/client-server/howto.rst
index ec941edddd..37346224af 100644
--- a/docs/client-server/howto.rst
+++ b/docs/client-server/howto.rst
@@ -31,7 +31,7 @@ Registration
The aim of registration is to get a user ID and access token which you will need
when accessing other APIs::
- curl -XPOST -d '{"user_id":"example", "password":"wordpass"}' "http://localhost:8008/_matrix/client/api/v1/register"
+ curl -XPOST -d '{"user":"example", "password":"wordpass", "type":"m.login.password"}' "http://localhost:8008/_matrix/client/api/v1/register"
{
"access_token": "QGV4YW1wbGU6bG9jYWxob3N0.AqdSzFmFYrLrTmteXc",
@@ -39,14 +39,15 @@ when accessing other APIs::
"user_id": "@example:localhost"
}
-NB: If a ``user_id`` is not specified, one will be randomly generated for you.
+NB: If a ``user`` is not specified, one will be randomly generated for you.
If you do not specify a ``password``, you will be unable to login to the account
if you forget the ``access_token``.
Implementation note: The matrix specification does not enforce how users
register with a server. It just specifies the URL path and absolute minimum
keys. The reference home server uses a username/password to authenticate user,
-but other home servers may use different methods.
+but other home servers may use different methods. This is why you need to
+specify the ``type`` of method.
Login
-----
diff --git a/docs/client-server/model/presence.rst b/docs/client-server/model/presence.rst
index 7e54505364..811bac3fab 100644
--- a/docs/client-server/model/presence.rst
+++ b/docs/client-server/model/presence.rst
@@ -1,103 +1,3 @@
-========
-Presence
-========
-
-A description of presence information and visibility between users.
-
-Overview
-========
-
-Each user has the concept of Presence information. This encodes a sense of the
-"availability" of that user, suitable for display on other user's clients.
-
-
-Presence Information
-====================
-
-The basic piece of presence information is an enumeration of a small set of
-state; such as "free to chat", "online", "busy", or "offline". The default state
-unless the user changes it is "online". Lower states suggest some amount of
-decreased availability from normal, which might have some client-side effect
-like muting notification sounds and suggests to other users not to bother them
-unless it is urgent. Equally, the "free to chat" state exists to let the user
-announce their general willingness to receive messages moreso than default.
-
-Home servers should also allow a user to set their state as "hidden" - a state
-which behaves as offline, but allows the user to see the client state anyway and
-generally interact with client features such as reading message history or
-accessing contacts in the address book.
-
-This basic state field applies to the user as a whole, regardless of how many
-client devices they have connected. The home server should synchronise this
-status choice among multiple devices to ensure the user gets a consistent
-experience.
-
-Idle Time
----------
-
-As well as the basic state field, the presence information can also show a sense
-of an "idle timer". This should be maintained individually by the user's
-clients, and the homeserver can take the highest reported time as that to
-report. Likely this should be presented in fairly coarse granularity; possibly
-being limited to letting the home server automatically switch from a "free to
-chat" or "online" mode into "idle".
-
-When a user is offline, the Home Server can still report when the user was last
-seen online, again perhaps in a somewhat coarse manner.
-
-Device Type
------------
-
-Client devices that may limit the user experience somewhat (such as "mobile"
-devices with limited ability to type on a real keyboard or read large amounts of
-text) should report this to the home server, as this is also useful information
-to report as "presence" if the user cannot be expected to provide a good typed
-response to messages.
-
-
-Presence List
-=============
-
-Each user's home server stores a "presence list" for that user. This stores a
-list of other user IDs the user has chosen to add to it (remembering any ACL
-Pointer if appropriate).
-
-To be added to a contact list, the user being added must grant permission. Once
-granted, both user's HS(es) store this information, as it allows the user who
-has added the contact some more abilities; see below. Since such subscriptions
-are likely to be bidirectional, HSes may wish to automatically accept requests
-when a reverse subscription already exists.
-
-As a convenience, presence lists should support the ability to collect users
-into groups, which could allow things like inviting the entire group to a new
-("ad-hoc") chat room, or easy interaction with the profile information ACL
-implementation of the HS.
-
-
-Presence and Permissions
-========================
-
-For a viewing user to be allowed to see the presence information of a target
-user, either
-
- * The target user has allowed the viewing user to add them to their presence
- list, or
-
- * The two users share at least one room in common
-
-In the latter case, this allows for clients to display some minimal sense of
-presence information in a user list for a room.
-
-Home servers can also use the user's choice of presence state as a signal for
-how to handle new private one-to-one chat message requests. For example, it
-might decide:
-
- "free to chat": accept anything
- "online": accept from anyone in my addres book list
- "busy": accept from anyone in this "important people" group in my address
- book list
-
-
API Efficiency
==============
diff --git a/docs/client-server/swagger_matrix/api-docs-directory b/docs/client-server/swagger_matrix/api-docs-directory
index ce12be8c96..5dda580658 100644
--- a/docs/client-server/swagger_matrix/api-docs-directory
+++ b/docs/client-server/swagger_matrix/api-docs-directory
@@ -48,6 +48,22 @@
"paramType": "body"
}
]
+ },
+ {
+ "method": "DELETE",
+ "summary": "Removes a mapping of room alias to room ID.",
+ "notes": "Only privileged users can perform this action.",
+ "type": "void",
+ "nickname": "remove_room_alias",
+ "parameters": [
+ {
+ "name": "roomAlias",
+ "description": "The room alias to remove.",
+ "required": true,
+ "type": "string",
+ "paramType": "path"
+ }
+ ]
}
]
}
|
