Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
MSC2409: Proposal to send EDUs to appservices #2409
base: old_master
Are you sure you want to change the base?
MSC2409: Proposal to send EDUs to appservices #2409
Changes from all commits
96213b5
c70ba2b
553837c
771cafe
7912fda
9339848
49f2087
4a06e25
fdee029
231084d
0c794bc
9d20145
91436e4
ce393b1
c21f86a
15f4582
d1783c4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick, perhaps, but since this file is describing the app service, should it be,
receive_ephemeral
rather than 'push'? (indeed, the comment below is phrased in this way too).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% on this but it feels slightly confusing that
ephemeral
here matches the newephemeral
section the body, but it also controls the presence of theto_device
section. Could it be clearer to just have a separate field to control whether the AS wants to_device messages (and maybe this could actually be useful for an AS to be able to subscribe to to_device message without getting presence, etc?)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed, maybe we should have separate settings for each of presence, typing, device lists, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion a filter would be best suited for a future MSC. Appservices already don't have an option to filter what events (PDUs) they receive, but it would be great if they could.
"Ephemeral" here is also inherited from the server-server API rather than client-server API: it includes to-device messages, but changes shape to be more useful as a representation. We could absolutely package it into
ephemeral
, but appservices will already be translating it to fit their crypto engine shape anyways - might as well give them something directly compatible.Overall, appservices being closer to federation than clients makes things weird. We should improve them, but I don't think this is the MSC to fix everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please can
to_device
be mentioned here (and probably in the example), rather than introduced as a plot twist halfway through the description (which I assumed until then was going to be all aboutephemeral
)?Alternatively, introduce the two arrays as separate changes with their own sections in the MSC.
Edit: oh, this has already been mentioned below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please be explicit about exactly what sort of events are included in
ephemeral
. AIUI, it's typing and presence? Or are there more? Read receipts? Device lists? Account data?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't appear to be the case, based on the example above. For example, the C-S API puts typing notifications under the corresponding
room
, so doesn't need a separateroom_id
key in them.typing
notification itself.I'm not really sure what the word "otherwise" is doing in this sentence.
Please be explicit about exactly what format each type of event should use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would maybe make more sense to wrap the to_device events in their own object which contains the metadata for this transport layer? ie.
...then there's no chance of overlapping keys (although obviously this would be unlikely anyway) and the receiving server can just take the inner object out and pass it on verbatim?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you'd need a name for the property that contains the inner object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Github doesn't seem to format
json5
as prettily asjson
. Can we usejson
orjsonc
here and below?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this get a mention back where the
ephemeral
key is introduced please? ie. give a summary of what's being added and then give the detail on each.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't the fact that the array can be omitted is anything to do with the way to-device messages work over federation, fwiw.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH in general I think the whole EDU concept was a terrible idea: each so-called EDU has its own special-casing, and the fact that the federation spec dumps them into a single
edus
property is a source of confusion (I've complained about this previously at matrix-org/matrix-spec#897 (comment)). We don't need to justify the fact that we are not repeating those mistakes here.Suggest getting rid of this text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strongly recommend writing explicit rules for each type of event, rather than handwaving about EDUs in general.
(Also, note again that EDUs don't exist as a concept at all outside the federation API)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to assume that a client somewhere is
/sync
ing with the same device ID as the appservice? And both devices want to receive the to-device message?I'll note that this does not yet seem to be implemented (element-hq/synapse#11423). Maybe that's ok since this is not a normative part of the MSC, but I'm a bit troubled that this is left undefined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really understand why we can only delete messages for users under an appservice's exclusive namespace. There's probably some explanation somewhere in the depths of matrix-org/synapse#10653, but it needs explaining here imho
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same is true of to-device messages?