MSC3173: Expose stripped state events to any potential joiner#3173
MSC3173: Expose stripped state events to any potential joiner#3173
Conversation
c5d73cb to
7fac8ac
Compare
7fac8ac to
1cfbf76
Compare
|
Since this is pretty much a clarification / expansion of current behavior, I don't think this really needs an implementation since...the current implementations already implement this. 😄 |
turt2live
left a comment
There was a problem hiding this comment.
Overall seems sane. It's a bit awkward that the MSC says the user can access the stripped state, but doesn't really describe how the user might encounter those events. Dedicated endpoints are probably still out of scope for this MSC, but some clarification around the unification of stripped state and when they might appear (potentially in future MSCs) would be appreciated.
| receive stripped state events to display metadata to users. | ||
|
|
||
| This MSC proposes formalizing that the stripped state that is currently available | ||
| to invited and knocking users is available to any user who could potentially join |
There was a problem hiding this comment.
Is “potentially join” recursive? I.e., if I'm in A, which allows joining B, which allows joining C, can I potentially join C?
There was a problem hiding this comment.
for the purposes of this MSC, no. Recursion like that would be determined in another access control MSC.
MSC3173: Expose stripped state events to any potential joiner
MSC3173: Expose stripped state events to any potential joiner
|
Spec PR: #3606 |
|
Merged 🎉 |
Rendered
FCP vote