WIP groups as rooms MSC

proposals/1772-groups-as-rooms.md

@@ -0,0 +1,166 @@
+# Proposal for groups as rooms (take 2)
+
+This obsoletes MSC1215.
+
+## Problem
+
+The current groups API has some serious issues:
+ * 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 existing across multiple
+   participating servers.
+
+## Solution
+
+Represent groups by rooms rather than a custom first-class entity.
+
+We reserve aliases which begin with a `+` to represent groups - e.g. the room
+for group `+test:example.com` is `#+test:example.com`.
+
+We introduce a `m.room.groups` state event which defines how a room should
+behave as a group - i.e. the rooms which it groups together, and any subgroups
+nested within it.
+
+```json
+{
+    "type": "m.room.groups",
+    "contents": {
+        "rooms": [
+            {
+                "room": "#room1:example.com",
+            },
+            {
+                "room": "#room2:example.com",
+                "autojoin": true
+            },
+            {
+                "room": "#room3:example.com",
+            },
+        ],
+        "subgroups": [
+            {
+                "group": "+something:example.com",
+            },
+            {
+                "group": "+otherthing:example.com",
+            },
+        ]
+    },
+}
+```
+
+Name, Topic, Membership etc share the same events as a normal room.
+
+The flair for a group is given by the room avatar.
+
+Long description requires a new event: `m.room.description`.  This can also be
+used for rooms as well as groups.
+
+Groups may be nested, and membership of groups is defined as the union of the
+members of the group room and its subgroups.  If `+top:example.com` has two
+subgroups, the user membership of `+top:example.com` is the union of the
+subgroups and the group itself.  This allows hierarchies of groups & users to be
+defined.
+
+Clients peek in rooms (recursing into subgroups as needed) in order to determine
+group membership.
+
+Invites, 3PID invites, Power Levels etc all work as for a normal room.
+
+Normal messages within the room could be showed and used as a 'lobby' area for
+the given group.
+
+This requires no server changes at all, other than better support for peeking
+(see Dependencies below), and could allow the existing /groups API to be
+deprecated and removed outright.
+
+## ACLs
+
+Currently the group server has total control over specifying the list of users
+who may be present in a group, 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 group structures into Matrix,
+it may be overengineered.
+
+Instead, the common case is wanting to define a group where some users are
+publicly visible as members, and others are not.  This is what the current use
+cases require today.  A simple way of achieving would be to create a subgroup
+for the private members - e.g. have +sensitive:matrix.org and +sensitive-
+private:matrix.org.  The membership of `+sensitive-private:matrix.org` is set up
+with `m.room.join_rules` to not to allow peeking; you have to be joined to see
+the members, and users who don't want to be seen by the public to be member of
+the group are added to the subgroup.
+
+XXX: is there a use case today for having a group where users are unaware of the
+other users' membership?  e.g. if I am a member of `+scandalous:matrix.org`
+should i have a way to stop other members knowing that I am?  One solution here
+could be "auditorium mode", where users cannot see other users' identities
+(unless they speak).   This could be added later, however, and would also be
+useful for normal rooms.
+
+## Flair
+
+TODO: We need to establish how users should safely advertise their flair.
+Perhaps they can claim whatever flair they like on their profile (MSC1769) and
+clients need to then doublecheck whether the assertion is true by peeking in the
+room in question to check it's true?
+
+## Dependencies
+
+This needs peeking to work effectively on CS API.
+
+This needs peeking to work effectively over federation (e.g. by having servers
+join remote rooms as @null:example.com in order to participate in them for
+peeking purposes).
+
+These dependencies are shared with profiles-as-rooms (MSC1769).
+
+## Security considerations
+
+XXX: how do we stop cycles & recursion abuse of the subgroups?
+
+## Tradeoffs
+
+This consciously sacrifices the ability to delegate group lookups through
+to a centralised group server.  However, group data can already be stale as we
+rely on cached attestations from federated servers to apply ACLs even if the
+remote server is not available.  So this isn’t much worse than eventually
+consistent group membership as you’d find in a room.
+
+It also means that large groups have to be bridged in their entirety into the
+room, rather than querying/searching incrementally.  This is something we should
+fix for bridged rooms in general too, however.
+
+This also consciously sacrifices the ability for a group server to provide
+different 'views' of groups to different querying users, as being
+overengineered.  Instead, all common use cases should be modellable by modelling
+group memnbership as room membership (nesting if required).
+
+## Issues
+
+How does this work with MSC1229 (removing MXIDs)?
+
+## History
+
+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