This is now a generic API on the homeserver. This is wrapped in a non-generic js-sdk function for now. In future, other group server implementations may want specific configuration and the configuration keys are namespaced to prevent collisions there.
The API on synapse was modified to be an upsert, which means the same API call for adding a room to a group can be used to update the visibility of that association.
bluebird doesn't support promise progression (or rather, it does, but it's
heavily deprecated and doesn't use the same API as q), so replace the
(undocumented) promise progression on uploadFile with a callback.
* Add group summary api
* Add doc for group summary API
and remove callback param as it's deprecated
* API for /joined_groups
* Create group API
* Make doc marginally more helpful
Check that /thirdparty/protocols gives us an object (rather than a string, for
instance). I saw a test explode, apparently because it gave us a string. Which
is odd, but in general we ought to be sanity-checking the things coming back
from the server.
* Add API for POST /user_directory/search
This takes a JSON body of the form:
```json
{
"term": "search term",
"limit": 42,
}
```
where "term" is the term to match against user IDs, display names and domains and "limit" is the maximum number of results to return (which is defaulted server-side).
The response body looks like
```json
{
"results ": [
{ "user_id": "@someid:mydomain.com", "display_name": "Some Name", "avatar_url": "mx://..." },
...
],
"limited": false
}
```
where "limited" indicates whether the "limit" was used to truncate the list.
* Implement API for setting RM
This is now stored on the server with similar treatment to RRs. The server will only store the specified eventId as the current read marker for a room if the event is ahead in the stream when compared to the existing RM. The exception is when the RM has never been set for this room for this user, in which case the event ID will be stored as the RM without any comparison.
This API also allows for an optional RR event ID to be sent in the same request. This is because it might be the common case for some clients to update the RM at the same time as updating the RR.
See design: https://docs.google.com/document/d/1UWqdS-e1sdwkLDUY0wA4gZyIkRp-ekjsLZ8k6g_Zvso/edit
See server-side PRs: https://github.com/matrix-org/synapse/pull/2120, https://github.com/matrix-org/synapse/pull/2128
* Functionality for msisdn signin
* Add methods to request tokens from synapse to do msisdn
verification
* Extend interactive-auth to work with m.email.identity (which
is significant since email auth is quite a chunk more complex).
* Oops, fix merge
* Fix lint
* Add submitMsisdnToken
* Support the bind_msisdn param to register
Change the bind_email flag to an object with keys 'email' and
'msisdn', backwards compatibly.
Extends the interactive-auth to support m.login.email.identity
This also includes the ability to resume a UI auth session given
the approirpiate information (ie. to resume the auth flow having
click a link in a verification email).
