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

MSC3510: Let users kick/ban/demote each other #3510

Closed
wants to merge 2 commits into from

Conversation

ara4n
Copy link
Member

@ara4n ara4n commented Nov 20, 2021

@ara4n ara4n added the proposal A matrix spec change proposal label Nov 20, 2021
@turt2live turt2live added client-server Client-Server API feature Suggestion for a significant extension which needs considerable consideration proposal-in-review s2s Server-to-Server API (federation) requires-room-version An idea which will require a bump in room version unassigned-room-version Remove this label when things get versioned. needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Nov 20, 2021
Comment on lines +23 to +24
We change the room auth rules (which currently seem to be implicit in the
spec?) to allow users to kick, ban or demote other users with the same power
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Event auth rules are specified per room version: https://spec.matrix.org/v1.1/rooms/v7/#authorization-rules

Copy link
Contributor

@Mikaela Mikaela left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clients must clearly educate users about the change in behaviour to avoid nasty surprises.

I totally agree on that part, but still have concerns on this being quite drastic change and I think education on what changes between room versions is lacking to users in general as the room version tends to be hidden.

I imagine discovering there are 10 different kinds of rooms in the wild can come as a confusing surprise especially to less technical users who simply wish to have their community on Matrix.

Comment on lines +34 to +35
each other becomes a social one: this can be mitigated by using finer
granular PLs (e.g. setting lesser trusted admins to PL 99, if needed). This
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this also bring a recommendation for clients to allow creating a room with arbitary maximum power level which some people are doing during room creation with the API?

Comment on lines +51 to +52
promote themselves to admin whatever happens. However, this is orthogonal to
this proposal and should be considered in a separate MSC.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whenever I see words similar to this, I fear that a partial solution gets implemented and the rest of the solution is somewhere in the future to be someone else's problem and should something bad happen between partial and full solution, I fear the one suffering from it gets blamed by upstream.

@Mikaela

This comment has been minimized.

@Mikaela

This comment has been minimized.


## Security considerations

This lets users enact coups on each other, in exchange for empowering admins
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There may be a further state resolution problem here which would prevent kicks/bans/demotion between two users of the same power level from ever becoming permanent.

The reverse topological power ordering (https://spec.matrix.org/unstable/rooms/v2/#definitions, 6th paragraph) specifies that such events are sorted according to power level of the sender. But if the power levels of the senders are equal, then origin_server_ts is used to resolve the tie. But origin_server_ts is spoofable by the homeserver.

So I think that if we have two admins A and M with equal power levels in a room, and M has their own homeserver, then we might not be able to have a hard guarantee that A is able to e.g. ban M. This is because when M sees the ban event, they can create another event with a lower origin_server_ts to e.g. ban A in return.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about event ID? Those are semi-random, right?

Though, I could imagine that is also spoof-able, given some more intensive iteration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because when M sees the ban event, they can create another event with a lower origin_server_ts to e.g. ban A in return.

I was assuming that we would need a change to state res to handle this. Perhaps it would be sufficient to tiebreak in favour of the admin who created the room, if any?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about event ID? Those are semi-random, right?

Yes, probably spoofable if someone was intent on doing it. Apart from that, resolving into a random but deterministic direction doesn't feel very satisfying.

I was assuming that we would need a change to state res to handle this. Perhaps it would be sufficient to tiebreak in favour of the admin who created the room, if any?

I guess that would be one way of solving it but I think this may be a better solution in this vein.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally in general I think it is fine that the kicked admin can react by spoofing an event to ban the banner first. However I think this is only ok if it is time-limited. The reason for this is that I don't see much difference between the reactionary ban and the proactive ban. I don't see why we should be committed to ruling in favour of quick-draw. However it say after 24h we could guarantee that the current resolution stuck then it seems that it would be fine for "peaceful" step-downs as the state is now stable.

Unfortunately I don't think we have any mechanism for this in the protocol. The only thing I can think of is allowing other users to "vouch" for the time that they saw the message. However backdating various sorts of events results in this breaking in all sorts of horrible and confusing ways into the future.

I think the only option left is majority vote. If you want to demote someone at the same power-level as you you must get more than half of the users at the same level to agree. But even that is vulnerable to backdating a promotion or invite.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because when M sees the ban event, they can create another event with a lower origin_server_ts to e.g. ban A in return.

There are multiple other ways they could exploit this. E.g. In the fork they invite a new user and give them admin rights. The new user will make it into the resolved room state.
Then the new user can just unban the other user again.

Comment on lines +10 to +11
* If the admin becomes abusive (e.g. due to change in circumstances, betrayal
of trust, compromise of their account)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A betrayal of trust or compromise of an account is also exactly why it works like it currently does. After this proposal is implemented, if one admin has their account compromised or goes rogue they can permanently take over the entire room by kicking all the other admins out.

Comment on lines +33 to +38
This means that the problem of avoiding admins (or mods) enacting coups on
each other becomes a social one: this can be mitigated by using finer
granular PLs (e.g. setting lesser trusted admins to PL 99, if needed). This
runs the risk of reintroducing the original problem however (that if an admin
with PL100 goes missing or goes rogue, there's no recourse but abandon the
room).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this proposal is a good idea. It seems like even after this proposal is implemented, it still remains a human decision to make, but now you are adding on the additional burden on clients and users where some rooms will work very differently than other rooms.

Room creators already have the choice to set additional admins at lower power levels so they can kick them out if they go rouge. If you want to change the spec, I think a better change would be to just have clients recommend that new admins get set at PL90 or PL99. It doesn't seem worth it to entirely change how power levels work technically just to fix one human problem and cause another.

Like @Mikaela said

still have concerns on this being quite drastic change and I think education on what changes between room versions is lacking to users in general as the room version tends to be hidden.
I imagine discovering there are 10 different kinds of rooms in the wild can come as a confusing surprise especially to less technical users who simply wish to have their community on Matrix.

The only way I can see this working is if you fix room upgrades so they are completely transparent to the user and essentially every room automatically gets upgraded to every new version so they all appear to work the same way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to change the spec, I think a better change would be to just have clients recommend that new admins get set at PL90 or PL99.

Agreed, i think adding an extra "owner" "role" would help, while admins become PL 99 or such, and some major roles are also added at PL 99 (but not room upgrades, i think)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this better than the proposal, too.

Copy link

@kfiven kfiven Nov 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Second that, we also added something like that in Cinny where room creator can assign themselves "Founder (PL 101)". We added this to solve problem with appservice because it was kicking matrix users for idling but IMO it would also work in cases like this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that having a "super-admin"/"owner"/"creator" role sounds like a better alternative. Many other chat systems work like this without obvious downsides. If other admins need to migrate (owner unresponsive), they can @room and ask room members to move, while changing topic and room alias.

Maybe that would be a good occasion to revisit one of the many role-based membership systems like #3073?


## Security considerations

This lets users enact coups on each other, in exchange for empowering admins
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adding a limitation that the room creator can't be demoted by any others? This would ensure that foreign admins cant takeover a room when getting hostile. I think that may be a reasonable limitation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also as @deepbluev7 mentioned this to me it might make sense to have this somewhere in a state event defined as there may at some point be a voted owner change of a room. So that would allow to protect some users if wanted.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't that be vulnerable to a Sybil attack? I think that would be very easy to abuse.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adding a limitation that the room creator can't be demoted by any others? This would ensure that foreign admins cant takeover a room when getting hostile. I think that may be a reasonable limitation.

The room creator might want to transfer ownership or define backup owners, otherwise it will create a single point of failure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's practical to ever involve the room creator tbh - people migrate accounts all the time, and rooms outlive admins. On the surface it makes sense, but I think it'd be a false sense of safety to support.

Further, there's a concern that if that single account gets deactivated or removed from a server for whatever reason then the room is essentially left to chaos. In cases of deactivation/shutdown for abuse, it's typically desirable that a room not be present on a particular server, but intentionally cannot be wiped off the federation - deactivating the room creator would effectively allow a single server more power than it should have regarding the affairs of the room.

Yes, the server could just puppet accounts on it and do similar amounts of damage, however in the vast majority of cases the reputational damage of doing so will prevent a server from ever being trusted by other users, regardless of how those users feel about the content of the affected room.

@Ai-rin

This comment has been minimized.

@274below

This comment has been minimized.

@richvdh
Copy link
Member

richvdh commented Nov 29, 2021

@Mikaela, @Ai-rin, @274below: please remember to make any comments on the "files changed" tab (https://github.com/matrix-org/matrix-doc/pull/3510/files), otherwise it becomes impossible to track which comments are still relevant.

I'll go through and hide the unthreaded comments so if you still feel your comments are valuable, please re-make them on the "files changed" tab.

Copy link
Contributor

@Mikaela Mikaela left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merging two still relevant comments after #3510 (comment).

Comment on lines +57 to +58
to have full control over their rooms. Clients must clearly educate users
about the change in behaviour to avoid nasty surprises.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On this requiring a lot of education should this pass, there is documentation around such as GNOME's Sovereignty on a Federated System: problems we faced on GNOME’s Matrix instance: Losing ownership which has prompted https://github.com/vector-im/element-web/issues/17634 and possibly a couple of other issues, which may lead into further confusion.


I imagine discovering there are 10 different kinds of rooms in the wild can come as a confusing surprise especially to less technical users who simply wish to have their community on Matrix.

The solution to this could be https://github.com/matrix-org/matrix-doc/issues/2564 and similar changes to deprecate the older room versions first before this change and having a proper flow for upgrading rooms instead of the current /upgraderoom which says it's an advanced operation that shouldn't be needed?

Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, it took me far too long to circle around to a composer to type this out.

I believe others have covered sentiments of the comments here, but just in case I've started a new thread.

@@ -0,0 +1,58 @@
# MSC3510: Let users with the same power level kick/ban/demote each other.
Copy link
Member

@turt2live turt2live Dec 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: the original version of this came off a bit stronger than I intended, so have brought it back a bit.

I'm largely concerned with how this proposal affects DMs - admins being able to demote or remove each other means that it's entirely possible that someone can restrict access to a private conversation. For business and professional cases this isn't so much of an issue as it can be resolved offline, however for the more casual cases (small communities, DMs, etc) it feels wrong to let the other party decide how accessible the conversation is.

Public rooms are generally quite a bit larger than private conversations, so it is feasibly possible for those to have this proposal's mechanics. It's much harder to take a room off the record when it's replicated 4-10x more than a private room (roughly).

In cases where a private room member was evicted, they'd essentially be left with options involving GDPR subject access requests to get their messages back if they didn't run their own homeserver at the time. This is relatively prevalent with public homeservers sticking around.

I would be comfortable if this proposal scoped itself to public and semi-public (knockable, restricted) rooms, but did not operate in invite-only private rooms and DMs.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically I agree, I wanted to raise this issue with DMs as well, but:

I would be comfortable if this proposal scoped itself to public and semi-public (knockable, restricted) rooms, but did not operate in invite-only private rooms and DMs.

What does prevent somebody from making a private room public and then apply the mechanics of this MSC?

There's also the valid usecase that something starts as DM and then you invite more and more people. If you want at some point be able to make the room public, it's possible to make it public as well. This flexibility is great and anything that hinders the conversion of DMs into public rooms, which will make the protection of DMs possible at all, will restrict this flexibility or the protection of DMs is a toothless tiger if this MSC applies.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More complicated DMs that start to involve more people are probably best covered by one of the DM-specific MSCs. As far as this MSC is concerned, a DM is just a private room that happens to be tagged as such.

There's also a point where the protocol can't really help or protect the users from themselves, such as deliberately making a room public just to demote others. Power levels can be configured ahead of time to prevent that in DMs, and the mechanism could try to distinguish between maliciously public and public (possibly some sort of dedicated state event which controls how the power level behaviour operates?). This quickly turns into having too many options, though.

Comment on lines +12 to +13
* If the admin is on a homeserver which is no more, they are stuck in the
roomlist forever
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is another solution to this problem than this MSC, I'll call it "soft kicking":
Everybody with a power level high enough to kick can also soft kick, even if the member being soft kicked has a higher (or the same, that's debatable) PL than the one soft kicking.
What this does is modifying the member state through either adding a field or changing the membership field to hold some sort of pseudo-leave value. All this does is instruct clients to hide those members from the room list. A member which has been erroneously soft kicked can reclaim it's membership which will revert the change in the member state.
So soft-kicking would be a non-destructive action but still solve this problem.

Comment on lines +15 to +19
We also have a problem that it is very disturbing that admins don't have full
control to admin the users in their room. Admins quite reasonably expect to
have full control over their room - much as root has full control on UNIX,
and the current behaviour is very jarring and a constant source of
complaints.
Copy link

@su-ex su-ex Dec 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What gets entirely mixed up and neglected in this MSC is the difference between owning something and administering something: Someone could own a huge skyscraper and still offload its administration (who is allowed to live/work there, cleaning, ...) to someone else who administers the building.
So an owner doesn't necessarily have to pursue any administrative tasks, but still can own it.
Nevertheless, an owner ranks higher than his administration in that he can instruct them what to do or replace them entirely.

It's perfectly fine if ownership is transferred: If I don't want that skyscraper anymore, hopefully someone else will buy it.
There was discussion here to special case the room creator in more or less obvious ways. Currently, the creator has no real relevance apart from the initial power level which is, however, obvious to everyone and makes him effectively the owner of the room. Transferring ownership is possible for the creator by promoting someone else and demoting himself. There shouldn't be any hidden meaning of the creator after that if the transfer of ownership was by intention.

It's also perfectly fine to co-own things:

  • If someone owns a part of a building and someone else owns another, neither of them can just take it all and rip off the other owner.
  • If someone owns part of a company (for example through shares), he cannot just take it all and rip off the other owners.
  • If someone pursues a project together with someone else, it can be said that they both put work into it and therefore own together what they built together. While not necessarily prohibited by law all over the world, it's still socially unacceptable in most places to simply neglect the work of others and claim it entirely your own.

However, this is what this MSC proposes.

Currently, promoting someone else to admin (be it a bridge or a real person) effectively leads to a shared ownership. This can be fine and it should not be possible for a single owner to demote another one (see above).

It has been discussed here to give other admins PL 99 by default as an alternative to this MSC for backwards compatibility with older rooms. While the idea is good, I fear exisiting rooms are often already a lost cause, and it's already possible for current admins to pay attention to what power they give away. While I'd prefer this solution by far compared to this MSC, I think both is no good because it's a very bad idea to change established values and behaviors.
It has also been mentioned to bump the creator as initially single owner to 101. This sounds far better as it clearly differentiates between owner and administrator and doesn't change established values and behaviors. However, I think it would be a good idea to bump the creator to at least 150 for increased flexibility (which would also fit good into the established values: 50, 100, 150):

  • Owners (PL 150): They own the room and have therefore full control over it (but cannot take it all if the ownership got shared by intention). At room creation, the creator is the only owner of the room.
  • Administrators (PL 100): Have been entrusted by the owners to administer the room. This can be a technical or social role. By default, administrators should have the same rights as owners (apart from maybe a very destructive, because non-revertible, action like enabling encryption).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I agree with the above reasoning regarding ownership and I think this may be the best way to move forward.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds perfectly reasonable to me. The only reason I suggested 90 (or 99) is that it is backwards compatible with existing rooms. >100 would only work in new rooms since you can't promote above the highest existing power level and 100 is the highest power level in the vast majority of rooms today.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need a new room version anyway, so it doesn't really matter if you are compatible with existing rooms. Also, rooms can arbitrarily redefine power_levels. I have a few with admins at 2^52. So this probably just needs an extra permission in power_levels and redefinition of the default PL event in new room versions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need a new room version

Why do you need a new room version to change the default PLs for new rooms?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need a new room version to change the default PLs for new rooms?

Ah, right, this thread is about none ever being able to kick anyone else with the same PL. I thought that was still pursued, my bad.

Comment on lines +5 to +19
Matrix currently doesn't let users with the same power level kick, ban or demote
each other. This particularly causes problems for room admins with power
level 100, as if a user is promoted to be an admin, there is no way to demote
them. Scenarios where this is problematic include:

* If the admin becomes abusive (e.g. due to change in circumstances, betrayal
of trust, compromise of their account)
* If the admin is on a homeserver which is no more, they are stuck in the
roomlist forever

We also have a problem that it is very disturbing that admins don't have full
control to admin the users in their room. Admins quite reasonably expect to
have full control over their room - much as root has full control on UNIX,
and the current behaviour is very jarring and a constant source of
complaints.
Copy link

@joshqou joshqou Jan 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This MSC creates significantly bigger problems than it solves.

Current Problems

Dead Admins

While it is annoying to have admins of dead homeservers clogging up your power level state, it's something that is easily solved by upgrading or tombstoning the room. This is a solution that many room admins already implement, and are fine with.

Compromised Admin Users

With the current power level behaviour, other room admins would retain their permissions until the original admin either regains control of his account, or the account is deactivated. From that point a room admin can tombstone the room to redirect users to a new room, or clean up the timeline and continue using the existing room if no destructive states were set.

"Admins quite reasonably expect to have full control over their room - much as root has full control on UNIX"

Even as root, there are some things you can't do. User misunderstandings lie on the client to resolve, not the spec.

Introduced Problems

Hostile Takeovers

Compromised admin accounts being able to enact hostile takeovers on rooms, giving their actual account admin, then de-opping the compromised admin account.

"Moderators" being able to ban other Moderators

This is behaviour that room admins are not going to expect, and aren't going to want.

Breaking Convension

Room admins are already familiar with the current "greater than" power level behaviour. If new users do not understand that giving a user PL 100 makes them the co-owner of the room, then the fault lies on the client for not properly signalling to them that's what that does.

Breaking Convension from all previous room versions

This MSC makes breaking changes to m.room.power_levels, and would prevent rooms from being cleanly upgraded.

Forcing changes for direct rooms

Direct rooms are currently created with co-ownership, a solution to retain current behaviour in direct rooms would need to be created.

Giving Admin becomes a Liability

Op'ing other users would become a liability given they act in malice or have their account compromised, as such an event could lead to a hostile takeover of the room. This could dissuade room admins from giving other users admin, and would make the current "dead admin" problem worse in the long run for smaller rooms.

Giving Moderator becomes a Liability

As moderators would be able to ban other moderators, one compromised or malicious moderator could ban all other moderators to allow a raid or spam attack to go unopposed. This could dissuade room admins from giving multiple users moderator permissions.


This is frankly not a good idea. The problems mentioned to justify this change already have existing solutions, such as tombstoning. While larger rooms may want a better solution than "just tombstone lol", that's a solution that should be provided as optional, not enforced on every future matrix room.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dead Admins
While it is annoying to have admins of dead homeservers clogging up your power level state, it's something that is easily solved by upgrading or tombstoning the room. This is a solution that many room admins already implement, and are fine with.

This has been discussed a bit in Feneas room recently. The room upgrade or tombstone in case of /upgraderoom copies the current event and to not carry the legacy event over, one has to perform a manual room upgrade, which I don't think is supported by any client directly, and which I worry would bring even more elitism ignoring non-technical users.

The threat model is that should a domain with administrator powers fall to wrong hands, they can take over rooms by creating accounts that have power as apparently federation key isn't required alongside controlling domain. This may however tie in with matrix-org/synapse#3765 which probably should have a mechanism for invalidating the power levels from intentionally dying homeserver. Then again that issue doesn't cover cases like where privacytools.io homeserver administrators lost control over the domain instead of a graceful shutdown.

@ara4n
Copy link
Member Author

ara4n commented Oct 23, 2022

@mscbot fcp close

In retrospect I hadn't thought this through properly at all - thanks all for the constructive review. I've opened #3915 as a replacement, which looks to almost entirely match @su-ex's comment at #3510 (comment).

@mscbot
Copy link
Collaborator

mscbot commented Oct 23, 2022

This FCP proposal has been cancelled by #3510 (comment).

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

Once at least 75% of reviewers approve (and there are no outstanding concerns), 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 information about what commands tagged team members can give me.

@mscbot mscbot added disposition-close proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. labels Oct 23, 2022
@turt2live turt2live added this to Needs idea feedback / initial review in Spec Core Team Backlog via automation Oct 24, 2022
@turt2live turt2live moved this from Needs idea feedback / initial review to Ready for FCP ticks in Spec Core Team Backlog Oct 24, 2022
@richvdh
Copy link
Member

richvdh commented Oct 24, 2022

The "fcp close" process is normally used when we decide to close someone else's proposal. Since @ara4n is the author, we don't need an FCP on closing this.

@richvdh richvdh closed this Oct 24, 2022
@turt2live
Copy link
Member

@mscbot fcp cancel

just to clean up the state machine

@mscbot mscbot added proposal-in-review and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-close labels Oct 24, 2022
@turt2live turt2live added obsolete A proposal which has been overtaken by other proposals and removed proposal-in-review labels Oct 24, 2022
@turt2live turt2live moved this from Ready for FCP ticks to Done to some definition in Spec Core Team Backlog Oct 25, 2022
@turt2live turt2live removed this from Done to some definition in Spec Core Team Backlog Oct 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API feature Suggestion for a significant extension which needs considerable consideration needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. obsolete A proposal which has been overtaken by other proposals proposal A matrix spec change proposal requires-room-version An idea which will require a bump in room version s2s Server-to-Server API (federation) unassigned-room-version Remove this label when things get versioned.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet