Skip to content
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

Documentation for the differences between "federation" and "client" event format #3305

Closed
richvdh opened this issue Aug 2, 2021 · 2 comments · Fixed by #3658
Closed

Documentation for the differences between "federation" and "client" event format #3305

richvdh opened this issue Aug 2, 2021 · 2 comments · Fixed by #3658
Labels
clarification An area where the spec could do with being more explicit

Comments

@richvdh
Copy link
Member

richvdh commented Aug 2, 2021

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
@MadLittleMods
Copy link
Contributor

MadLittleMods commented Sep 4, 2021

Looks like it may be documented here, Persistent Data Unit (PDU), https://spec.matrix.org/unstable/rooms/v1/#event-format

But I would expect to find out and link to that from https://spec.matrix.org/unstable/server-server-api/

@richvdh
Copy link
Member Author

richvdh commented Sep 6, 2021

I'm planning to cover this as part of some work on #684. Bear with me for a week or two.

richvdh added a commit that referenced this issue Feb 1, 2022
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 `/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.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the spec could do with being more explicit
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants