-
Notifications
You must be signed in to change notification settings - Fork 412
MSC1772: Matrix spaces #1772
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
MSC1772: Matrix spaces #1772
Changes from 16 commits
Commits
Show all changes
89 commits
Select commit
Hold shift + click to select a range
6c499db
WIP groups as rooms MSC
ara4n 346f7ac
add hyperlinks
ara4n 1e81fbd
md
ara4n a884fd8
wordwrap fix
ara4n 43ae6ad
md
ara4n e00eff5
add thought about splitting events
ara4n cd5a842
flesh out how flair could work
ara4n 19e9420
flesh out state events split per state-key for defining groups
ara4n 010246e
typo
ara4n 88ff3de
spell out deps
ara4n 54bf339
typo
ara4n 1bbe638
typo
ara4n 417501d
various minor edits
richvdh 96cd76c
remove 'one big event' proposal
richvdh 6464e90
Merge branch 'master' into matthew/msc1772
richvdh 0baf49a
We are not considering hidden-membership rooms yet
richvdh 4040254
Update for new terminology and current thinking
richvdh 52853b5
more updates
richvdh c145d39
Notes on propagating PLs etc
richvdh 15f34e5
supporting trad PLs
richvdh e746aa3
Apply suggestions from code review
richvdh 2f557da
Clarifications to room/space relationship
richvdh 11bb604
add an xxx
richvdh d42da58
Apply suggestions from code review
richvdh 1aede33
clarify introduction
richvdh e323ade
Switch to room IDs
richvdh a73dd9c
clarification
richvdh 839ea0e
inheriting join rules
richvdh 109c31c
Avoiding abuse via false `parent` claims
richvdh 06b5c83
notes on children and recursion
richvdh 29b07c1
update power level mappings
richvdh ae71a62
Restricting room membership via spaces
richvdh b40f7da
Record alternatives
richvdh 4e3b0ed
add a length limit to `order`
richvdh 3b2825f
Descope autokick and rename allowed_spaces
richvdh e6a6941
rename allowed_join again
richvdh fbad757
update dependencies links
richvdh 1f1e3c9
MSC1840 is in
richvdh d4abe40
one parent per room
richvdh 39af7f3
Update 1772-groups-as-rooms.md (#2866)
grinapo 45f2608
No cross-room auth
richvdh 6cc3995
explain a bit
richvdh 51aa5e2
Update proposals/1772-groups-as-rooms.md
richvdh 6989758
Update proposals/1772-groups-as-rooms.md
richvdh 037894a
replace 'default' with 'auto_join'
ara4n 803e70a
typo
ara4n 42c332b
fix parent claiming plurality
ara4n 2de3dc4
more plurality fixing
ara4n 302d5d8
clarify autojoin and mention 'suggested' rooms
ara4n a0d06c7
factor out ACLs into a separate MSC
ara4n b8e3a0b
include invite state notes
ara4n f8fb325
replace m.room.parent with m.space.parent for symmetry
ara4n 343e1f6
incorporate @joepie91's clarification on secret rooms
ara4n 97103c4
clarify that auto-joins are not force joins
ara4n 91fe7a7
switch to allowing multiple parents
ara4n b10856d
let's create spaces with `events_default` PL100
ara4n a0f89bd
add XXX about via propagation
ara4n a709671
tie break on multiple parents
ara4n ff85e61
fix dev identifier
ara4n 1cfe6bc
MSC1840 is out again.
richvdh bc14662
related MSCs
richvdh 62b9154
Remove lost footnotes
richvdh 469b64c
rip out m.room.description
richvdh dcb18f0
Move security consideration to MSC2962
richvdh 7d757ce
minor wording tweaks
richvdh acdb6f1
Move "auto-join" out to "future extensions"
richvdh 2e6d7d1
spaces are *primarily* referred to by their room ID.
richvdh 0bdbec2
Accept m.space.parent links if there is a reverse link
richvdh 6c9d469
add an issue about lost parent links
richvdh 8a61ce9
remove 'present' flag
richvdh c0c5138
Move "via" problem to a "potential issue"
richvdh 9ca9423
Suggested rooms
richvdh 5e7ed2b
Tweak wording about lexicographic ordering
richvdh 065b099
Update proposals/1772-groups-as-rooms.md
richvdh e704152
Include `create` in invite_room_state
richvdh 6d007e8
Defer a TODO to the future.
clokep 12d08ca
Consistency and update links.
clokep 00912f9
clarify how to deterministically cut cycles
ara4n f07e82e
clarify the charsets of our lexicographic orderings
ara4n 37e04f7
tiebreak ordered spaces sensibly
ara4n 1e2ed52
add more justification for immutable room types
ara4n 0d71150
remove confusing mention of peeking & dependent MSCs
ara4n 7432d25
incorporate travis feedback
ara4n 2981baa
Update proposals/1772-groups-as-rooms.md
ara4n acdf985
incorporate uhoreg feedback
ara4n 413e346
note the rationale behind using the # sigil
ara4n 757218c
relax requirements on cycle-cutting and link to valere's alg
ara4n c2d0d1e
include m.room.create in knock_state (will be overtaken by MSC3173)
ara4n 9773759
Remove cycle breaking algorithm to be specced in the future, if neces…
clokep File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,207 @@ | ||
# Proposal for groups as rooms (take 2) | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
richvdh marked this conversation as resolved.
Show resolved
Hide resolved
|
||
This obsoletes [MSC1215](https://github.com/matrix-org/matrix-doc/issues/1215). | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
## 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 replicated across all | ||
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`. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
We introduce `m.room.group` and `m.room.subgroup` events which define the rooms | ||
and subgroups within the group. A `present: true` key is included to | ||
distinguish from a deleted state event. Something like: | ||
|
||
```json | ||
{ | ||
"type": "m.room.group", | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
"state_key": "#room1:example.com", | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
"contents": { | ||
"present": true | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
} | ||
} | ||
|
||
{ | ||
"type": "m.room.group", | ||
"state_key": "#room2:example.com", | ||
"contents": { | ||
"present": true, | ||
"autojoin": true | ||
} | ||
} | ||
|
||
richvdh marked this conversation as resolved.
Show resolved
Hide resolved
|
||
{ | ||
"type": "m.room.subgroup", | ||
"state_key": "+something:example.com", | ||
"contents": { | ||
"present": true | ||
} | ||
} | ||
{ | ||
"type": "m.room.subgroup", | ||
"state_key": "+otherthing:example.com", | ||
"contents": { | ||
"present": true | ||
} | ||
richvdh marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
``` | ||
|
||
Name, Topic, Membership etc share the same events as a normal room. | ||
|
||
The flair image for a group is given by the room avatar. (In future it might | ||
preferable to use hand-crafted small resolution images: see | ||
[matrix-doc#1778](https://github.com/matrix-org/matrix-doc/issues/1778). | ||
|
||
Long description requires a new event: `m.room.description`. This can also be | ||
used for rooms as well as groups. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
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. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
Clients peek in rooms (recursing into subgroups as needed) in order to determine | ||
ara4n marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
group membership. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
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. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
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. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
## ACLs | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
richvdh marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
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. | ||
|
||
In future, there may be a usecase for groups where members are unaware of the | ||
other users' membership. This would also be useful for other rooms, and is left | ||
for a future proposal. | ||
|
||
## Flair | ||
|
||
A proposal for how to safely determine user flair is: | ||
|
||
* User publishes the groups they wish to announce on their profile | ||
([MSC1769](https://github.com/matrix-org/matrix-doc/issues/1769) | ||
as a m.flair state event: it lists the groups which they are advertising. | ||
|
||
* When a client wants to know the current flair for a set of users (i.e. | ||
those which it is currently displaying in the timeline), it peeks the | ||
profile rooms of those users. However, we can't trust the flair which the | ||
users advertise on the profile - it has to be cross-referenced from the | ||
memberships of the groups in question. | ||
|
||
To do this cross-referencing, options are: | ||
|
||
1. The client checks the group membership (very inefficient, given the server | ||
could/should do it for them), or... | ||
2. The server checks the group membership by peeking the group and somehow | ||
decorates the `m.flair` event as validated before sending it to the client. | ||
This is also inefficient, as it forces the server to peek a potentially large | ||
group (unless we extend federation to allow peeking specific state events) | ||
3. The origin `m.flair` event includes the event_id of the user's | ||
`m.room.membership` event in the group. The server performing the check can | ||
then query this specific event from one of the servers hosting the group-room, | ||
and we perhaps extend the S2S API to say whether a given state event is current | ||
considered current_state or not. If the `m.room.membership` event is confirmed | ||
as current, then the `m.flair` is decorated as being confirmed. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
Of these, option 3 feels best? | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
## Dependencies | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
This needs peeking to work effectively over the CS API | ||
([MSC1776](https://github.com/matrix-org/matrix-doc/issues/1776)). | ||
|
||
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 - [MSC1777](https://github.com/matrix-org/matrix-doc/issues/1777)). | ||
|
||
These dependencies are shared with profiles-as-rooms | ||
([MSC1769](https://github.com/matrix-org/matrix-doc/issues/1769)). | ||
|
||
## Security considerations | ||
|
||
XXX: how do we stop cycles & recursion abuse of the subgroups? | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
## 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 | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
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. | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
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 membership as room membership (nesting if required). | ||
|
||
## Issues | ||
|
||
How does this work with | ||
[MSC1228](https://github.com/matrix-org/matrix-doc/issues/1228) (removing MXIDs)? | ||
richvdh marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
||
## Unstable prefix | ||
|
||
While this proposal is not in a published version of the specification, | ||
implementations should use `org.matrix.msc1772` to represent the `m` | ||
namespace. For example, `m.room.subgroup` becomes | ||
`org.matrix.msc1772.room.subgroup`. | ||
|
||
|
||
## 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 |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.