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

Clients should generate a unique ID - is ambiguous when sending messages. unique wrt what? (SPEC-282) #131

Closed
matrixbot opened this issue Nov 30, 2015 · 1 comment
Labels
A-Client-Server Issues affecting the CS API clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@matrixbot
Copy link
Member

Submitted by @​matthew:matrix.org

(Imported from https://matrix.org/jira/browse/SPEC-282)

@matrixbot matrixbot changed the title Clients should generate a unique ID - is ambiguous when sending messages. unique wrt what? Clients should generate a unique ID - is ambiguous when sending messages. unique wrt what? (SPEC-282) Oct 31, 2016
@matrixbot matrixbot added the spec-bug Something which is in the spec, but is wrong label Nov 7, 2016
@richvdh richvdh added clarification An area where the expected behaviour is understood, but the spec could do with being more explicit and removed spec-bug Something which is in the spec, but is wrong labels Nov 8, 2017
@turt2live turt2live assigned turt2live and unassigned turt2live Sep 6, 2018
@turt2live turt2live added the A-Client-Server Issues affecting the CS API label Sep 6, 2018
@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
@uhoreg
Copy link
Member

uhoreg commented Oct 4, 2022

I think that this is fixed by #1236 adding a link to the section explaining transaction IDs

@uhoreg uhoreg closed this as completed Oct 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API 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

4 participants