MSC2175: Remove the creator field from m.room.create events

[richvdh]

Rendered

Fixes #1193

Implementation: matrix-org/synapse#15394

[KitsuneRal]

No objections from the client perspective.

[turt2live]

finally, thank you!

[richvdh]

I'm going to assume that the only reason not to do this is tuits, so

@mscbot fcp merge

[mscbot]

Team member @richvdh has proposed to merge this. The next step is review by the rest of the tagged people:

• @KitsuneRal
• @anoadragon453
• @ara4n
• @dbkr
• @erikjohnston
• @richvdh
• @turt2live
• @uhoreg

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[anoadragon453]

Looks like a good cleanup, thanks.

@mscbot reviewed

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[ara4n]

fwiw, the reason for the creator field was i think to support moving creator ownership around in subsequent events somehow. but given this has never been figured out, i’m happy to remove the redundancy and readd correctly jn future if needed

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[turt2live]

This is now formally assigned to room version 11: #3820

[turt2live]

Spec PR: matrix-org/matrix-spec#1604

[richvdh]

A thought, belatedly, occurs about this.

The obvious fix, for clients, is to fall back to sender where creator is not present (as indeed has been done in https://github.com/vector-im/element-ios/pull/7635/files, cc @pixlwave)

However, as of v11, creator is totally unprivileged; it is under the control of the client (via creation_content in the /createRoom call). So a user could create a v11 room, and claim that someone else made it by setting creator to a different user.

The question is whether that matters in practice.

[turt2live]

Merged 🎉

[anoadragon453]

However, as of v11, creator is totally unprivileged; it is under the control of the client (via creation_content in the /createRoom call). So a user could create a v11 room, and claim that someone else made it by setting creator to a different user.

The question is whether that matters in practice.

No special privileges are currently given to the creator of a room (other than allowing them to initially join the room), so I'm not sure what implications this would actually have. The only thing that comes to mind is moderation tooling; some tooling could attempt to clean up all rooms created by a certain user. And perhaps that tool was written before v11 rooms existed, and would be searching for m.room.create->content->creator across all rooms.

Still, I'm not familiar with any moderation tooling that erases rooms based on creator, rather than message content. Perhaps this is just a reminder that client-side tools that act on rooms should scope themselves to a set of known room versions - and warn if they find any that it does not know the rules for.