3 ms·
I'm the author of the spec issue this blog post is based on: https://github.com/matrix-org/matrix-spec/issues/852 https://github.com/matrix-org/matrix-spec/issu
by timokoesters 2y ago
I'm the author of the spec issue this blog post is based on: https://github.com/matrix-org/matrix-spec/issues/852 https://github.com/matrix-org/matrix-spec/issues/852
In my implementation for the Conduit Matrix server, the /sync order is used for everything. The timeline is just one list that grows on one end for incoming events and on the other end for backfilled events.
I think it's important that the message order does not change, because that's very difficult to communicate to the user.
- moritzruth 2y agoA few years ago, I started writing a Matrix client library for Kotlin. At one point, I had to make an API decision based on how messages are ordered. When I found this issue, I subscribed to it and planned on continuing with my library when the spec was clarified. Given how foundational this spec unclarity is, I thought it wouldn't take too long. Well.
- solarkraft 2y agoOne idea of mine was to continue when Matrix 2.0 would be stable. Might still have some time.
- Fizzadar 2y agoOh that’s neat (TIL), am also working on a HS that also does this [1]. Not only does it feel like the most correct (I don’t think there is a perfect) behaviour for the user but also makes implementation much simpler. Synapse has a LOT of ordering foo and magic in the code I still don’t fully understand and I’ve gone fairly deep into synapse at times for work. [1] https://github.com/Beeper/babbleserv https://github.com/Beeper/babbleserv