Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-11 08:33:42 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

clarify introduction

Browse source
This commit is contained in:
Richard van der Hoff 2020-11-09 12:30:02 +00:00
parent d42da585e5
commit 1aede33b35
1 changed files with 39 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

71
proposals/1772-groups-as-rooms.md
View file

@ -17,40 +17,18 @@ purposes. Examples include:
We refer to such collections of rooms as "spaces". We refer to such collections of rooms as "spaces".
Synapse and Element-Web currently implement an unspecced "groups" API which Synapse and Element-Web currently implement an unspecced "groups" API (referred
attempts to provide this functionality (see to as "`/r0/groups`" in this document) which attempts to provide this
[matrix-doc#1513](https://github.com/matrix-org/matrix-doc/issues/1513)). This functionality (see
API has some serious issues: [matrix-doc#971](https://github.com/matrix-org/matrix-doc/issues/971)). However,
* It is a large API surface to implement, maintain and spec - particularly for this is a complex API which has various problems (see
all the different clients out there. [appendix](#appendix-problems-with-the-r0groups-api)).
* 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.
In this document, the existing implementation will be referred to as
"`/r0/groups`".
This proposal suggests a new approach where spaces are themselves represented This proposal suggests a new approach where spaces are themselves represented
by rooms, rather than a custom first-class entity. This requires few server by rooms, rather than a custom first-class entity. This requires few server
changes, other than better support for peeking (see Dependencies below). The changes, other than better support for peeking (see Dependencies below).
existing `/r0/groups` API would be deprecated in Synapse and remain
The existing `/r0/groups` API would be deprecated in Synapse and remain
unspecified. unspecified.
## Proposal ## Proposal
@ -523,12 +501,41 @@ implementations should use `org.matrix.msc1772` to represent the `m`
namespace. For example, `m.space.child` becomes namespace. For example, `m.space.child` becomes
`org.matrix.msc1772.space.child`. `org.matrix.msc1772.space.child`.
## History ## History
* This replaces MSC1215: https://docs.google.com/document/d/1ZnAuA_zti-K2-RnheXII1F1-oyVziT4tJffdw1-SHrE * This replaces MSC1215: https://docs.google.com/document/d/1ZnAuA_zti-K2-RnheXII1F1-oyVziT4tJffdw1-SHrE
* Other thoughts that led into this are at: https://docs.google.com/document/d/1hljmD-ytdCRL37t-D_LvGDA3a0_2MwowSPIiZRxcabs * Other thoughts that led into this are at: 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.
## Footnotes ## Footnotes