| 30 Mar 2024 |
|  @tekolote:chat.tekolote.co left the room. | 04:12:53 |
|  jb431 joined the room. | 20:28:59 |
| 2 Apr 2024 |
|  Andrew Morgan (anoa) changed their display name from Andrew Morgan (anoa) [UTC-6] to Andrew Morgan (anoa) [away; back Apr 4]. | 00:45:13 |
|  threestan joined the room. | 13:29:43 |
|  Neil changed their display name from neil_away to neil. | 14:04:24 |
| 3 Apr 2024 |
|  __z__ joined the room. | 04:53:08 |
| 4 Apr 2024 |
| Neil changed their display name from neil to neil_away. | 08:24:23 |
| Andrew Morgan (anoa) changed their display name from Andrew Morgan (anoa) [away; back Apr 4] to Andrew Morgan (anoa). | 08:53:34 |
| 6 Apr 2024 |
|  Ricardo Duarte changed their display name from RicardoD to Ricardo Duarte. | 23:02:42 |
| 8 Apr 2024 |
|  Till changed their display name from Till [away - back 8th April] to Till. | 06:06:24 |
| Neil changed their display name from neil_away to neil. | 09:13:33 |
| 9 Apr 2024 |
| Neil changed their display name from neil to Neil. | 13:46:34 |
| 11 Apr 2024 |
 herkulessi | Is it necessary to keep Messages in arrival orderfor the Sync and messages APIs and the works, or is it allowed to reorder Event arrivals based on the DAG-Order? Because It seems to me that Synapse, Conduit and Dendrite all just put the events in the Timeline in arrival order, event after an initial sync (Haven't actually looked at code, just from experience) | 08:16:33 |
 andybalaam | APIs like /messages and /relations require messages in "topological" order (see e.g. https://spec.matrix.org/v1.5/client-server-api/#get_matrixclientv1roomsroomidrelationseventidreltype ) | 08:46:11 |
| andybalaam | /sync is approximately in order of arrival at the homeserver | 08:46:38 |
| andybalaam | There's some stuff about ordering in here that might help a bit: https://docs.google.com/presentation/d/1H1gxRmRFAm8d71hCILWmpOYezsvdlb7cB6ANl-20Gns/edit?usp=sharing | 08:48:03 |
| andybalaam | And this proposal might shed some light: https://github.com/matrix-org/matrix-spec-proposals/pull/4033 | 08:48:59 |
| andybalaam | Basically, it's hard for clients at the moment to find a consistent ordering | 08:49:11 |
 Matthias | Hey, this room has quite an old version (v5), would it be possible to do a room upgrade to a more recent version, such as v10? | 18:04:15 |
 bkil | What's the benefit? | 18:49:44 |
| Matthias | Mainly for newer server implementations which do not (properly) implement this room version. | 19:26:18 |
| bkil | When implementing a new homeserver, which is the set of room versions that you would consider mandatory before the first public release would go live? | 19:31:02 |
| Matthias | Lemme check where I read this, but I think the idea is that by the time you have started building a server on the latest version at the time of starting, that version should be a few version behind the latest by the time you get things stable for federation. | 19:46:13 |
 clokep | You'll want to at least implement the latest "default" room version and any newer than that... currently that's 9+ IIRC. | 20:06:18 |
| clokep | But you might need to support older ones since...people don't upgrade rooms often. 😄 | 20:06:35 |
| Matthias | Yes, that is a problem. That is why I am suggesting we do so. 🙂 | 20:07:55 |
| Matthias | One less room contributing to the problem. | 20:08:28 |
 Cat | In reply to @clokep:matrix.org
You'll want to at least implement the latest "default" room version and any newer than that... currently that's 9+ IIRC. The default room version is 10 currently. | 23:15:39 |
| Cat | So it would be 10 and 11 under the Default and Newer logic currently | 23:24:12 |
| 13 Apr 2024 |
|  @jordan:bancino.net left the room. | 12:05:24 |
