When I look at Slack Engineering’s flowchart on whether to send notifications or not (and cutting back on its gargantuan memory usage), I can’t help but wonder whether any of this should have been built on top of XMPP somehow and written in a language other than JavaScript

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

Mind you, I understand how much time and energy go into developing polished products for the masses

My point is that less time and less energy could be spent by selecting different platforms to build on in the first place

@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.

@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. :/

@fluffy @cypnk It's in draft with recent changes. Not exactly promising for implementations.

@astraluma @fluffy @cypnk also, the flow chart is completely user-centric. Take away a few paths, and slack still works - just a little worse. It is of very little consequence if you implement all of it in JavaScript, Rust, Erlang or Brainfuck.

@amenthes @astraluma @cypnk Yeah, but it's too bad that they control all the implementations :/

@amenthes @fluffy @cypnk yes, but the chart was not actually the point of the post, just the impetus.

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.

Sign in to participate in the conversation

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!