It's quite disappointing that there's huge ongoing work around reinventing clients from scratch where the basic functionality of not ringing all my devices while I'm using only one of them [1] is still not there (bug open for years), despite it being a pretty simple fix.
The team rewriting Element as Element X is completely different to the folks who would need to make the change in Synapse to not send push to devices who are currently syncing. Agreed we should have fixed this years ago, especially as it's actually a feature in our pre-Matrix system back in 2012. There's basically a blindspot on long-lived missing serverside features like this; i've added it to a new hitlist we're experimenting with for trying to clear these up.
I offered a simple fix: delay notifications on all except the active client for 30 seconds, if a read reciept gets triggered from the active client then cancel the timer. I couldn't even get anyone in the team to even look at my solution 3 years ago.
Not sure why this feature keeps getting defered for "just about to land and things might be better after" server-side features (see how it has 7 out of 9 "dependencies" resolved) when none are needed.
I've had a couple of friend actually give up on matrix due to this. I also have to keep my phone on silent or else I can't be chatting on matrix without the constant bzzzing.
I'm also amused about the ever growing (currently at $760) bounty on this feature.
The project is a mess, which is obvious if one follows it. There is only slow progress. Instead of focusing everyone on one thing to do it right, they focus on multiple things that remain half-baked forever, e.g. multiple concurrent implementations like Synapse and Dendrite, Element and Hydrogen, Element and Element X, etc. pp. They seem to have organizational challenges, stemming from technical founders who didn’t know that it takes more than technical knowledge to build a great product. I believe they’ve learned somethings, e.g. that Element’s UI has always been crap hence Element X now, which they’ve denied for a long time. But they are surely still learning, e.g. how to be a focused and decisive leader, etc.
A project is always in large a reflection of the leaders. It’s the messy hackathon type project - not the clear and polished corporate project.
The reason historically for multiple concurrent implementations is because we're building a protocol, and multiple implementations dogfoods that - plus the different implementations service different segments. In practice, Hydrogen and Dendrite are currently deprioritised in favour of focusing on polishing Element X and Synapse. And Element Mobile is in security-maintenance mode only in favour of Element X.
Meanwhile, we massively fixed Element Mobile's UI a year ago: https://element.io/blog/an-unrecognisable-improvement-elemen... - and Element X is essentially the same UI... but on a different engine. So I'd argue that we were very aware that Element's UI was crap, which is why we fixed it. Rewriting the Element mobile apps as Element X is unquestionably the right thing to do in terms of sharing the same rust codebase between the two platforms and letting the app layer focus on UI.
Agreed that our progress has been slow, and our focus been has very broad at points. But we got there in the end, and certainly have learned from the journey (and built Matrix to be a much broader and successful heterogenous ecosystem as a result).
I'm sure your projects are all much more successful though - I'm jealous! :D
Actually, thinking about it now, the one thing I would prefer is if you could, in a 2-person room, have one participant's messages come up on the left while your own were on the right, or vice versa.
There are quite a few issues that they've stopped fixing in the Element app in favor of doing it in Element X, the one I've been following is where the iOS app causes a breakage in E2EE when you use the share extension, so they just disabled the share extension entirely and said they'd fix in X - https://github.com/vector-im/element-ios/issues/7618
But X requires Sliding Sync on the server, which is still a separate service to run alongside the homeserver and doesn't have a stable API. I am increasingly disappointed with how centralized Matrix is becoming, since AFAIK there isn't really an alternate client close to the same level of quality as Element.
I probably would've made all of the same decisions myself though, so I don't blame them I'm just a bit disappointed in how it's shaking out.
Is it really that simple though? Jabber tried to be smart about which device to ring, and sometimes someone ended up with a missed notification. I always felt gutting that complexity and ring all instead would have been the more robust way.
So you consider your phone vibrating loudly on your desk for every recieved message while you're actively chatting and reading the same message on your desktop a correct implementation?
Well slack doesn't even send me the messages to my desktop continuing to send to my phone (which continues to buzz) despite me writing on the desktop, just because I send a message on my phone 10min ago.
So it might not be that easy (if even slack with their funding can't get it right).
Yes, I don't want any clever tricks from my chat clients. I dislike this kind of under-the-hood magic. Client should just receive the message and send a notification if it's not silenced.
What about P2P multicasting between devices? Delay for 1 second, if you get an "I did the beep for message hash X" notice in that time from a higher priority device that is currently being looked at, don't.
A bit of a privacy leak on shared networks revealing which IP is doing messaging, but it should be fast and reliable.
[1] https://github.com/vector-im/element-meta/issues/360