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

The limited flag in Timeline in /sync response needs clarification #1664

Open
erikjohnston opened this issue Oct 19, 2023 · 1 comment
Open
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

@erikjohnston
Copy link
Member

Link to /sync spec.

It currently says:

True if the number of events returned was limited by the limit on the filter.

However, there are also the following cases:

Generally, limited means that there is more events the client can request with /messages

@erikjohnston erikjohnston added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Oct 19, 2023
@richvdh richvdh added the A-Client-Server Issues affecting the CS API label Apr 9, 2024
@Benjamin-L
Copy link

Conduit/grapevine/conduwuit currently set limited: true when returning a response with a gap. I interpret a gapped sync response as a consequence of this text from the filter spec:

The maximum number of events to return, must be an integer greater than 0.

Servers should apply a default value, and impose a maximum value to avoid resource exhaustion.

In this interpretation, a gap in the timeline occurs because the server has imposed a maximum or default value on the filter limit that is lower than the total number of events in the request's sync window. This is just a special case of the response being limited by the limit field in the filter, and so we set limited: true.

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

3 participants