3 ms·

I think the model of having all events form a giant graph is overengineered. They tried to cope with this by introducing things like "fast room joins", but I th

I think the model of having all events form a giant graph is overengineered. They tried to cope with this by introducing things like "fast room joins", but I think they are flawed and treat the symptom rather than the cause of the problem. Servers should only replicate the very core part of a room and fetch remaining information on demand. But I'm working together with the Matrix team to improve this in the future. I think most other things in the spec are necessary complexity. It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on, but they allow Matrix to have a lot of great features. What problems did you encounter writing bots for Matrix?

treyd 3y ago
The impression I got from using Ruma's bot SDK library was that bot clients needed to keep around a lot of state involved in syncing the room to handle new messages properly. Which largely lines up with what you said, although maybe it's possible I could have gotten away with a more lightweight solution since I wasn't making a stanalone client? > It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on Another impression I got was this was kind of an excessive amount of duplication (and other duplications) that could have been avoided had a bit more forethought been put into the protocol design, especially with how these features interact with the e2ee.