-
Notifications
You must be signed in to change notification settings - Fork 379
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
MSC3999: Add causal parameter to /timestamp_to_event
#3999
base: main
Are you sure you want to change the base?
MSC3999: Add causal parameter to /timestamp_to_event
#3999
Conversation
/timestamp_to_event
/timestamp_to_event
Instead of only defining a timestamp, we add an optional `event_id` query parameter | ||
which represents a topological spot in the DAG that we can easily determine what comes | ||
before or after from (a casual relationship). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should clarify that this should be added to the client
and federation
(server) /timestamp_to_event
API's
Instead of only defining a timestamp, we add an optional `event_id` query parameter | ||
which represents a topological spot in the DAG that we can easily determine what comes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Event ID's are globally unique but we're after a topological position in the DAG which is per-room so the event lookup should be constrained to the room.
Instead of only defining a timestamp, we add an optional `event_id` query parameter | ||
which represents a topological spot in the DAG that we can easily determine what comes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when event_id
can't be found?
Should the homeserver try to backfill the event from other homeservers?
What error code should we throw if we can't find it in any case?
|
||
In less scrupulous scenarios or with bad intentioned actors, these timestamp loops can | ||
occur throughout the room timeline. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another case why the causal parameter is useful: Events can occur at the same exact time and it's not possible to get the next one with /timestamp_to_event
atm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the purpose is to allow Matrix Public Archive to go back through events in the room, why not use /messages and the from/to/start/end fields for pagination?
MSC3999: Add causal
?event_id=$abc
query parameter to/timestamp_to_event
to signal that we want to keep progressing from this event regardless of what timestamp shenanigans are going on.Rendered
Server implementations:
Other related references:
/timestamp_to_event
(jump to date) was introduced, MSC3030: Jump to date API endpoint #3030