[timokoesters]

I'm the author of the spec issue this blog post is based on: 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]

A 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]

One idea of mine was to continue when Matrix 2.0 would be stable. Might still have some time.

[Fizzadar]

Oh 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