MSC4170: 403 error responses for profile APIs#4170
Conversation
f68e635 to
6ec8f9d
Compare
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
6ec8f9d to
ca54955
Compare
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
… partially compatible with this proposal
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
turt2live
left a comment
There was a problem hiding this comment.
overall the concept looks great - just a few small details to clarify before this is set for FCP imo.
@richvdh I think this issue has actually already been addressed through MSC3550. Have commented on the issue. |
|
We're building a multitenant solution based on matrix (homeserver is Synapse). An important part of this is delegating user_directory/search to our own backend to enforce user discoverability. If a user is discoverable (according to rules enforced in our custom user_directory) it must also be possible to invite the user to a room. Currently Element require a profile lookup to be able to do so. The solution is to allow profile lookups WITHOUT requiring users to share a room (using the synapse setting mentioned above). AFAIK nothing in the spec mandates such a flag, but IMO the spec shoul make a mention that HS implementation MAY (or SHOULD) allow opting into profile lookup (non 403/404 responses) even if a user is not in a public or shared room. Unrelated to this specific MSC, but the spec should perhaps also spell out the requirements to be allowed to invite someone into a room? |
|
Thanks for the feedback from an actual use case! 🙏
Leaving servers the freedom to allow profile look-ups in more, possibly even all cases was definitely the intention of this proposal. It's implicitly captured in this paragraph. The room membership conditions are only a "minimum" requirement and servers "MAY" (not MUST) deny profile queries if these conditions are unmet. Whether it's worth spelling this out further is probably a discussion for the matrix-spec pull request1 that follows if and when this proposal is accepted.
Interesting question. This is probably best covered in an issue on https://github.com/matrix-org/matrix-spec. Footnotes
|
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
|
Spec PR: matrix-org/matrix-spec#1867 |
|
Merged! 🎉 |
Rendered
Relates to matrix-org/matrix-spec#1867
In line with matrix-org/matrix-spec#1700, the following disclosure applies:
I am a Systems Architect at gematik, Software Engineer at Unomed, Matrix community member and former Element employee. This proposal was written and published with my gematik hat on.
FCP tickyboxes