It seems a lot of software is a never-ending cycle of finding solutions to problems that shouldn’t exist
Or were largely solved a decade ago
@cypnk And if all the platform owners (except Unix/Linux) were not working against standardization in an effort to lock in developers...
@Tryphon It feels like such a terribly missed opportunity
A lot of FOSS projects have come a long way toward better usability, but there’s still a lot more work to do. Unfortunately, closed-source companies usually have more funding to throw at the problem
@cypnk And less fragmentation to deal with.
I don't see it as "lost opportunity" as much as a deliberate (and very successful) tactic though.
@cypnk yeah it is
@valeg I heard about this but haven’t tried it yet. Maybe I should take a peek
@cypnk it's cute but without AP support it kinda bummer((
@cypnk welcome to the world of enterprise software
@cypnk That's got nothing to do with implementation, everything to do with insane design by committee.
@mdhughes There are just so many things stuck in implementations just because someone in the committee had influence too
And there it is forever since it’s too much trouble to take outa and maybe some obscure device needed it during the Blood Moon (See: OpenSSL)
@cypnk XMPP wouldn't have solved this problem, because mobile and push.
A lot of standard protocols were written with long-lived connections in mind (eg, a desktop with a high ratio of uptime to downtime, so it was more online than not). XMPP shares many of the same engineering assumptions as AIM and its ilk.
@cypnk Mobile is offline first. It is generally sleeping, waking up when it receives a push notification (a very optimized path provided by the platform and providers), and then it may wake up and connect to the server. Or it may wait until the user opens the app to connect.
XMPP has an extension to handle some of this (XEP-0198), which is still a draft. But what it doesn't handle is push.
Oh, and designing a good protocol is only half the work _at best_ (I suspect the number is closer to a third or less, and interoperability work would have taken a good chunk of time instead).
@astraluma @cypnk XMPP also had way too strong a concept of connection/session affinity which made it maddening to use when you regularly switch between multiple machines. Like I'd be at home and start a conversation with someone, then at work a few hours later they'd reply - but it would go to my home machine rather than the machine I was actually at.
I know XMPP eventually got extensions to support backscroll/sync et al but I never found an implementation that supported it. :/
Also, they didn't design the system to be that complicated. It evolved into that because of the complexity of human interaction and notifications and dealing with long term settings (I actually don't care about this channel/sever) vs short term ones (please don't distract me) and exceptions to all of this.
@cypnk I have no inside information but I strongly suggest that part of the complexity here has to do with different teams in the org owning different pieces of the experience, and that this flowchart willfully disregards the org structure that partitions this flow into discrete chunks in order to make a point about How Hard This Is.
It *is* hard, but the diagram implies one entity is responsible for the entire rubrik, which I very much doubt.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!