You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There doesn't seem to be any clear documentation of the differences between "federation" and "client" event format.
A non-exhaustive list:
clients always get an event_id even where this does not exist in the federation format
a bunch of fields present in the federation format are stripped out before sending to clients; examples: depth, origin, auth_events, prev_events, hashes, signatures.
other fields such as prev_content, prev_sender and age are added to unsigned.
server event format over federation
The text was updated successfully, but these errors were encountered:
Fixes#3305Fixes#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 `/sync`
and `/notifications`, and one by everything else (the difference being whether `room_id` is included).
In an ideal world, we wouldn't repeat `SerialisedEvent` every time it's used, and instead just link to the
first reference, but 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.)
There doesn't seem to be any clear documentation of the differences between "federation" and "client" event format.
A non-exhaustive list:
event_id
even where this does not exist in the federation formatdepth
,origin
,auth_events
,prev_events
,hashes
,signatures
.prev_content
,prev_sender
andage
are added tounsigned
.The text was updated successfully, but these errors were encountered: