Skip to content

MSC2002: Proposal for adopting MSC1884 as v4 rooms #2002

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.

Sign up for GitHub

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
richvdh merged 7 commits into from
May 21, 2019
Merged

MSC2002: Proposal for adopting MSC1884 as v4 rooms #2002

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
502d787
proposal for adopting MSC1884 as v4 rooms
ara4n May 17, 2019
bc55552
fix sublists
ara4n May 17, 2019
16602b7
fix sublists
ara4n May 17, 2019
0cce488
fix typo
ara4n May 17, 2019
a3ff82b
spell out that we're not planning to force upgrades to v4
ara4n May 17, 2019
917a1f1
fix thinkos
ara4n May 17, 2019
7fbbd57
thinko
ara4n May 19, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
spell out that we're not planning to force upgrades to v4
  • Loading branch information
@ara4n
ara4n committed May 17, 2019
commit a3ff82b4569ed4ab0e2ad08d132c8c50d6930a37
24 changes: 15 additions & 9 deletions proposals/2002-rooms-v4.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,8 @@ expressing room IDs as url-safe base64 rather than plain base64 for the
convenience of client implementors.

It is not proposed that servers change the default room version used when
creating new rooms.
creating new rooms, and it is not proposed that servers recommend upgrading
existing rooms to v4.

## Rationale and Context

Expand All @@ -20,14 +21,19 @@ algorithm in upcoming Matrix 1.0. We do not want to default to creating v3
rooms due to the inconvenience the v3 room ID grammar might cause, so instead
we are proposing favouring v4.

Ideally we would also include other room algorithm changes in v4 (e.g. honouring
server signing key validity periods, as per
https://github.com/matrix-org/synapse/issues/4364), but as spec & implementation
work is still ongoing there, we are proposing using v4 as a ubiquitous room
version which can be circulated before Matrix 1.0 and then used as the initial default
for creating rooms. The expectation is for the versions of the spec which coincide
with 1.0 to also support v5 rooms, but in practice v5 will not be marked as default
until it has sufficient adoption on the public network.
Ideally we would also include other room algorithm changes in v4 (e.g.
honouring server signing key validity periods, as per
https://github.com/matrix-org/synapse/issues/4364), but as spec &
implementation work is still ongoing there, we are proposing using v4 as a
room version which can be supported in the wild before Matrix 1.0 and then
used as the initial default for creating rooms. The expectation is for the
versions of the spec which coincide with 1.0 to also support v5 rooms, but in
practice v5 will not be marked as default until it has sufficient adoption on
the public network.

The expectation is never to recommend upgrading existing
rooms to v4, but instead v5 (once ready), to avoid overburdening room admins
with upgrade notifications.

To conclude, the proposed plan is:
1. Define room v4 as MSC1884
Expand Down