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

Move definitions of event and account_data schemas out of the C-S spec #896

Open
richvdh opened this issue Sep 20, 2021 · 0 comments
Open
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@richvdh
Copy link
Member

richvdh commented Sep 20, 2021

The client-server spec contains definitions of many different event types, scattered throughout the document:

I think it's confusing that we conflate the mechanism for sending and receiving events (the C-S API) with the events that can be sent. Furthermore:

  • In most cases servers don't actually care about the events at all.
  • These event definitions are a significant part of the length of the C-S spec, and their inclusion there makes it hard to understand and navigate the C-S spec
  • It's also hard to find the definition of a given event type.
  • This is less of an argument now than it used to be, thanks to MSC2844, but adding new event types shouldn't need changes to the C-S spec.

I think we could also make a similar argument for account data types (https://spec.matrix.org/unstable/client-server-api/#midentity_server, https://spec.matrix.org/unstable/client-server-api/#events-6, https://spec.matrix.org/unstable/client-server-api/#key-storage, https://spec.matrix.org/unstable/client-server-api/#events-14, etc).

@richvdh richvdh added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Sep 20, 2021
@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

1 participant