Hacker News Reader

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.

View on HN

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.

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

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

Reply on news.ycombinator.com