Distinguish 'client' from 'federation' events #3658
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
richvdh
commented
Jan 19, 2022
Comment on lines
21
to
48
| sent. This field is generated by the local homeserver, and may be incorrect | ||
| if the local time on at least one of the two servers is out of sync, which can | ||
| cause the age to either be negative or greater than it actually is. | ||
| sent. | ||
| type: integer | ||
| redacted_because: | ||
| description: The event that redacted this event, if any. | ||
| title: Event | ||
| type: object | ||
| transaction_id: | ||
| description: | | ||
| The client-supplied transaction ID, for example, provided via | ||
| `PUT /_matrix/client/r0/rooms/{roomId}/send/{eventType}/{txnId}`, | ||
| if the client being given the event is the same one which sent it. | ||
| type: string | ||
| prev_content: | ||
| description: | | ||
| The previous `content` for this event. This field is generated | ||
| by the local homeserver, and is only returned if the event is a state event, | ||
| and the client has permission to see the previous content. | ||
| x-changedInMatrixVersion: | ||
| 1.2: | | ||
| Previously, this field was specified at the top level of returned | ||
| events rather than in `unsigned` (with the exception of the [`GET | ||
| .../notifications`](/client-server-api/#get_matrixclientv3notifications) | ||
| endpoint), though in practice no known server implementations honoured | ||
| this. | ||
| title: EventContent | ||
| type: object |
There was a problem hiding this comment.
all this stuff has moved into the definition for client_event, because it's not sent over the federation API, so IMHO doesn't belong in the core event schema.
|
looks like I need to figure out why the validator is failing. |
richvdh
force-pushed
the
rav/event_serialisation
branch
from
1b1633f
to
ec18c98
Compare
turt2live
requested changes
Jan 25, 2022
data/api/client-server/definitions/serialised_event_without_room_id.yaml
Outdated
Show resolved
Hide resolved
data/api/client-server/definitions/serialised_event_without_room_id.yaml
Outdated
Show resolved
Hide resolved
data/api/client-server/definitions/serialised_event_without_room_id.yaml
Outdated
Show resolved
Hide resolved
data/api/client-server/definitions/serialised_event_without_room_id.yaml
Outdated
Show resolved
Hide resolved
data/api/client-server/definitions/serialised_event_without_room_id.yaml
Outdated
Show resolved
Hide resolved
Co-authored-by: Travis Ralston <travisr@matrix.org>
richvdh
changed the title
This was referenced Feb 1, 2022
66 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #3305
Fixes #3380
The idea here is to better distinguish between a 'raw' event (as we send over the wire), and the 'serialised' format, as sent in responses to the C-S api and in
PUT /_matrix/app/v1/transactions/{txnId}.It's made more complicated by the fact that there are two serialisation formats, one used by
/syncand/notifications, and one by everything else (the difference being whetherroom_idis included).In an ideal world, we wouldn't repeat
SerialisedEventevery time it's used, and instead just link to the first reference, bit that's a job for another day.Another job for another day is to get rid of things like
sync_state_event.yaml(which is now used only in one place, so should be inlined.)Preview: https://pr3658--matrix-org-previews.netlify.app