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

Account data section needs cleanup #2030

Open
richvdh opened this issue Dec 13, 2024 · 1 comment
Open

Account data section needs cleanup #2030

richvdh opened this issue Dec 13, 2024 · 1 comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit good first issue This is a fix that might be an easy place for someone to start for their first contribution help wanted Interested in contributing to the spec? These would be great additions!

Comments

@richvdh
Copy link
Member

richvdh commented Dec 13, 2024

Link to problem area:

https://spec.matrix.org/v1.12/client-server-api/#client-config

Issue

  • For some reason, it is called "Client config" in the spec, when literally nobody calls it that
  • It refers to account data as "events", when they really really aren't that. (They might appear as event-like things when sent down /sync or /events, but that's something else.) Related: Spec refers to EDUs and account data as "events" #897
  • Lots of bits of the spec refer to "account data" but don't hyperlink back to the spec section on account data
  • Room tags are built on top of account data, but appear before account data in the spec, so that feels backwards.
  • The "client config" (i.e. account data) section has specific information about m.tag ("m.tag events appearing in /events will have a room_id with the room the tags are for"), which seems like it should be common to all room-based account data.
@richvdh richvdh added help wanted Interested in contributing to the spec? These would be great additions! clarification An area where the expected behaviour is understood, but the spec could do with being more explicit good first issue This is a fix that might be an easy place for someone to start for their first contribution labels Dec 13, 2024
@richvdh
Copy link
Member Author

richvdh commented Dec 13, 2024

I've labelled this as "good first issue", but if you'd like to pick this up as the first issue you work on, I suggest starting by fixing one of the things in the above list, rather than trying to solve them all at once.

@richvdh richvdh mentioned this issue Dec 14, 2024
3 tasks
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 good first issue This is a fix that might be an easy place for someone to start for their first contribution help wanted Interested in contributing to the spec? These would be great additions!
Projects
None yet
Development

No branches or pull requests

1 participant