MSC3968: Poorer features #3968
MSC3968: Poorer features #3968
Conversation
|
Signed-off-by: Valentin Lorentz <progval plus matrixsignoff at progval dot net> |
turt2live
added
proposal
Co-authored-by: Hubert Chathi <[email protected]>
Similarly to MSC3969.
| early to the user, or themselves fallback using any extra context they may have. | ||
|
|
||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
One of the biggest features that needs restricted on bridges is the set of allowed reactions. For example, iMessage only allows 5 reactions. I would be interested to see if this proposal could be adapted to handle that use-case.
There was a problem hiding this comment.
Hmm, this should probably be its own MSC, because it sounds like it's going to be its own can of worms (a whitelist like this, blacklist, only allowing emojis, unicode versions, ...).
| @@ -0,0 +1,248 @@ | |||
| # MSC3968: Poorer features | |||
There was a problem hiding this comment.
At the risk of bikeshedding too much, I'm wondering if we should call this "reduced featureset" modes or something? I'm just wondering if "poorer" is a good multi-lingual phrase.
Anyway, my 2c.
There was a problem hiding this comment.
It's a reference to Matthew's original ticket ("disable richer features") ;)
There was a problem hiding this comment.
Maybe "feature availability preferences," although that uses some long words
|
|
||
| ### Format of `m.room.event_features` | ||
|
|
||
| `m.room.event_features` events may have these keys: |
There was a problem hiding this comment.
Could this proposal be expanded to consider read receipts?
It is desirable for some rooms to discourage sending and displaying read receipts, such as rooms bridged to platforms that don't support read receipts, or for announcement rooms with thousands of members where each member doesn't need to know if other members have read a particular message.
| - using `"forbidden"`, `"discouraged"`, and `"acceptable"` as levels instead of integers. | ||
| This prevents finer grained display rules (eg. receiving clients may choose to hide events matching | ||
| levels under -50, because they are "very discouraged" by the administrator) and future | ||
| extendability (eg. values over 100 meaning an entity is required). |
There was a problem hiding this comment.
It makes more sense to me to use these names instead of integers. If level 0 is considered acceptable, what would a level of e.g. +37 even mean?
With integers, clients would end up choosing arbitrary number thresholds at which to activate or deactivate a certain feature in the interface. Non-human clients would also end up with arbitrary number thresholds programmed into them at which they'd change their behaviour. Among other problems, this would lead to inconsistency between clients when they each choose different numbers.
I think it makes more sense to directly specify the semantic meaning and intent, so I highly support using labels like "discouraged".
|
Hi @progval , if you closed this because you are no longer interested in seeing this MSC to completion, could I try to continue it? |
turt2live
added
the
abandoned
|
I closed it because Element is blocking implementation so I don't think it's going to go anywhere, but sure go ahead |
|
to be clear, Element isn't blocking any implementation, and this is a desirable MSC from my pov, and i'd suggest reopening it. |
|
@ara4n These PRs have been stuck in review by Element employees for seven months while accumulating merge conflicts: |
|
@progval thank you so much for your work on this, this is an important proposal that would make all manner of bridge implementations better – and I'm sorry this has been hanging. I was glad to sit in on this month's Spec Core Team retro and we took some time to discuss this. There's broad agreement that we'd love to see this MSC through. Part of the discussion was acknowledgment that Element hasn't allocated the resources to keep this moving, and that we may need other contributors to step in. It's not yet clear where that would come from, but everyone is aligned: this is valuable and we'd love to see this re-opened so that potential contributors see the opportunity. I'm sorry I can't offer concrete resolution, but did want to at least make sure you know this is something we value and want to see land in the spec even if it takes longer than we'd like. |
Could you clarify how other contributors can step in and merge their own pull requests? Is this documented somewhere, I think this would be important information to document. |
In general, from a completely spec standpoint, PRs don't need to be merged to count as implementation for MSCs. In addition, this could be implemented in other bridges. Though I recognize that it can be demotivating to have a PR sitting unreviewed for a long time, and it can be a pain to re-implement something for a different bridge. However, since the spec process doesn't require PRs to be merged to count as an implementation, nothing on the spec side is being blocked by the PRs not being merged. Skimming through the MSC, it looks like it's pretty much ready for review, so the main things that would be needed here are a client implementation (showing how a client would behave with an |
I was ready to start working on Eleweb as soon as my AS-irc PRs were accepted. But if it's also never merged in Eleweb, then I don't see the point. |
|
maybe it would be good to document requirements like this in CONTRIBUTING.md, so that contributors aren't left guessing for months |
The proposal process is documented at https://spec.matrix.org/proposals/ and the implementation requirement specifically is at https://spec.matrix.org/proposals/#implementing-a-proposal The problem isn't that the requirements are undocumented, because there is documentation. But the proposal process documentation is quite long. But in general, if contributors are wondering what the next step is for their MSC, the best thing to do is to ask in the #sct-office:matrix.org room. |
So from a purely spec perspective, having such a PR would help this MSC get accepted. But in this particular case, I suspect that you care less about what the spec says, and you care more about the implementations getting merged so that Element users stop making a mess of IRC rooms. So I can understand the frustration of not having the PRs merged, and I can understand that having such a long delay can be demotivating in doing any further work in this topic. I can't say much about the merging of the Application Service PRs, because I don't have anything to do with that. But since this issue is in a Spec repository, I can reiterate what others have said, that from the Foundation's point of view, we would like to see something like this in the Spec. And if @progval doesn't want to continue working on it, maybe someone else can push it forward. As I said earlier, it looks like we would need an implementation in some client, and then asking for FCP to be called. (Though if this MSC remains closed, then someone would have to open a new MSC.) |
|
For posterity: this is something we want in Matrix. if @progval isn't in position to reopen this, I suggest that whoever next comes along opens a new MSC for something similar and creates new implementation branches. |
|
I am writing a new proposal based on the review feedback here and I will link it here when I create the PR. |
|
I have created MSC4110 Fewer Features. |
Rendered
This MSC is meant primarily for bridges to signal to clients which "richer features" are not supported, allowing clients to hide or prioritize UI elements so their users do not unwittingly send events that would be bridged either badly or not at all.
This addresses the largest part of problems listed by matrix-org/matrix-spec#836 that cannot be solved with power levels. MSC3969 will address the remaining (size limits)