Skip to content
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

Upgrading a room can orphan it from its space #460

Open
robintown opened this issue Feb 26, 2022 · 4 comments
Open

Upgrading a room can orphan it from its space #460

robintown opened this issue Feb 26, 2022 · 4 comments
Labels
A-Room-Upgrades A-Spaces Spaces, groups, communities O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Spec-Changes

Comments

@robintown
Copy link
Member

robintown commented Feb 26, 2022

Steps to reproduce

  1. As User A, create a space
  2. Add Room A to the space
  3. Invite User B to the space and Room A
  4. Make User B an admin in Room A, but not the space
  5. As User B, upgrade Room A to Room B
  6. Invite User C to the space and Room B

For context, while this is an uncommon scenario, it's already happened in the Element Corp. space.

Outcome

What did you expect?

User C should see Room B listed as a child of the space.

What happened instead?

To User C, Room B appears as an orphaned room, since the space actually only lists Room A as a child, and User C has no way to know about the upgrade.

Well, that's not entirely true. User C could find out about the upgrade by looking at the room creation event. But if the room were upgraded twice rather than once, this would still not be enough information to connect the upgraded room back to Room A.

I'm not sure how this could be resolved. Perhaps spec changes?

Operating system

NixOS unstable

Browser information

Firefox 97.0.1

URL for webapp

develop.element.io

Application version

Element version: 95de708f4ee7-react-1a6134e441ba-js-53aa34fba57c Olm version: 3.2.8

Homeserver

Synapse 1.52.0

Will you send logs?

No

@robintown robintown added T-Defect S-Major Severely degrades major functionality or product features, with no satisfactory workaround A-Spaces Spaces, groups, communities O-Uncommon Most users are unlikely to come across this or unexpected workflow X-Spec-Changes A-Room-Upgrades labels Feb 26, 2022
@t3chguy
Copy link
Member

t3chguy commented Feb 26, 2022

Well, that's not entirely true. User C could find out about the upgrade by looking at the room creation event. But if the room were upgraded twice rather than once, this would still not be enough information to connect the upgraded room back to Room A.

This also can be abused, I could create NefariousRoom which claims to be an upgrade of MatrixHQ and now anyone joining the room would see it in the Matrix Community space wrongly

@ericdecanini
Copy link

Slightly related: There's confusion even on Android about what should happen during a room upgrade with regards to how the old room shows within its space.

element-hq/element-android#6411

"The pre-upgraded room would disappear only when the upgrade invite is accepted"
I think we should aim for this behaviour on all platforms. What do you think @robintown?

@robintown
Copy link
Member Author

@ericdecanini That certainly sounds a bit more reasonable that what currently happens

@Mikaela
Copy link

Mikaela commented Jul 3, 2022

I have a somewhat related spec issue open on rewriting restricted join rules when a room/Space is upgraded. matrix-org/matrix-spec#1072

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Room-Upgrades A-Spaces Spaces, groups, communities O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Spec-Changes
Projects
None yet
Development

No branches or pull requests

4 participants