Spec unsigned.membership property, per MSC4115
#1847
Conversation
|
ugh this has made it appear in the AS API, which is not the intention |
|
oh, maybe it's fine. I'll add a couple more words. |
| implement it in encrypted rooms). The property is *not* normally populated | ||
| in the application service API (where there is no clear definition of "requesting user"). |
There was a problem hiding this comment.
I couldn't find this bit about application services in the MSC -- I would think you'd populate it with whoever the AS is acting as?
There was a problem hiding this comment.
yeah, we didn't really think about this during the MSC; the "not normally populated" comes from the fact that the synapse impl doesn't populate it.
I would think you'd populate it with whoever the AS is acting as?
The problem is that, typically, an AS doesn't just act as one user. Sure it often has a "primary" mxid for the AS as a whole (@irc:matrix.org, or so), but I'm not sure if that mxid's membership of a given room is either here or there.
I guess it all ties into if/how e2ee works for ASes, which I now can't remember.
There was a problem hiding this comment.
I was thinking the "virtual user" provided by the user_id query parameter: https://spec.matrix.org/v1.10/application-service-api/#identity-assertion
But now we're kind of making stuff up that's not in the MSC. So probably best to leave it and if someone else wants it for AS they can define that in a new MSC.
There was a problem hiding this comment.
ah, I think we're at cross-purposes a bit.
By "the application service API", I am specifically referring to events sent to the AS via PUT /_matrix/app/v1/transactions/{txnId} requests to the AS; in that case there is no "virtual user". (And, having confirmed with @Half-Shot how E2EE works for ASes, I don't think it makes sense to include membership there).
Seems like I need to reword this a bit for clarity.
There was a problem hiding this comment.
| implement it in encrypted rooms). The property is *not* normally populated | |
| in the application service API (where there is no clear definition of "requesting user"). | |
| implement it in encrypted rooms). The property is *not* normally populated | |
| in events pushed to application services via the application service transaction API | |
| (where there is no clear definition of "requesting user"). |
There was a problem hiding this comment.
That sounds good, can you add a cross link to the AS docs?
There was a problem hiding this comment.
yeees, but then it looks even more ridiculous in the AS docs itself
There was a problem hiding this comment.
What do you mean that it looks ridiculous? I'm ok with it as is, if you think it looks best now.
There was a problem hiding this comment.
What do you mean that it looks ridiculous?
Currently, under https://pr1847--matrix-spec-previews.netlify.app/application-service-api/#put_matrixappv1transactionstxnid, we have:
That looks moderately ridiculous imho (why is it listed at all?), but it's hard to do much about. OTOH, if it links straight back to https://pr1847--matrix-spec-previews.netlify.app/application-service-api/#put_matrixappv1transactionstxnid, it might be even sillier.
Or maybe we should accept the awkwardness, and at least linking it would be clear?
There was a problem hiding this comment.
Ah -- the same bit gets added in both endpoints. I understand now. 👍 So yes -- I agree that would be a silly link to include.
I think ideally it wouldn't even be listed on the AS spec, but I have no idea how much refactoring that would need.
data/api/client-server/definitions/client_event_without_room_id.yaml
Outdated
Show resolved
Hide resolved
…d.yaml Co-authored-by: Johannes Marbach <[email protected]>
cf MSC4115
Preview: https://pr1847--matrix-spec-previews.netlify.app